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Silent  Inspector  System  Technical  Manual  (TR  DRP-96-1) 


ISSUE:  Inspection  of  dredging  operations  can 
be  greatly  assisted  by  automatic  logging  of 
dredging  activities  and  creation  of  dredging 
reports.  Development  of  a  system  to  assist 
inspectors  in  this  capacity  was  the  goal  of  this 
project 

RESEARCH:  A  Dredge  Operations  Silent 
Inspector  System  (DOSIS),  developed  to  auto¬ 
matically  log  data  from  instruments  generally 
maintained  aboard  hopper  dredges,  compute 
the  dredging  activities  occurring  and  the  quan¬ 
tity  of  material  retained,  and  provide  summa¬ 
ries  of  this  information  in  both  reports  and 
graphical  displays,  has  been  developed  and  is 
undergoing  testing  and  improvements.  While 
the  system  was  designed  for  use  aboard  hop¬ 
per  dredges,  its  basic  concept  will  be  applied 
to  other  dredge  types  in  the  future. 

SUMMARY :  This  report  describes  how  the 
Silent  Inspector  system  for  hopper  dredges  oper¬ 
ates  internally  assuming  the  system  has  already 


been  installed  by  a  systems  engineer.  This 
report  is  intended  to  be  used  by  systems  engi¬ 
neers.  A  companion  Silent  Inspector  User’s 
Manual  describes  how  to  operate  the  installed 
system. 

AVAILABILITY  OF  REPORT:  The  report  is 
available  through  the  Interlibraiy  Loan  Service 
from  the  U.S.  Army  Engineer  Waterways 
Experiment  Station  (WES)  Library,  telephone 
number  (601)  634-2355.  National  Technical 
Information  Service  (NTIS)  report  numbers  may 
be  requested  from  the  WES  library. 

To  purchase  a  copy  of  the  report,  call  NTIS 
at  (703)  487-4780. 
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Preface 


This  technical  manual  was  prepared  for  the  U.S.  Army  Engineer  Waterways 
Experiment  Station  (WES)  under  Dredging  Research  Program  (DRP)  Technical 
Area  4,  Work  Unit  No.  32482,  “Silent  Inspector.”  The  DRP  is  sponsored  by 
Headquarters,  U.S.  Army  Corps  of  Engineers  (HQUSACE).  HQUSACE  Tech¬ 
nical  Monitor  for  Technical  Area  4  was  Mr.  M.  K.  Miles. 

This  technical  manual  was  written  by  Mr.  Jeffrey  Cox,  Evans-Hamilton, 
Inc.,  Seattle,  WA;  Mr.  Paul  Maresca,  AdaSoft,  Inc.,  Laurel,  MD;  and 
Mr.  James  Rosati  III,  WES.  Technical  oversight  was  provided  by  Mr.  James 
Rosati,  Principal  Investigator,  Prototype  Measurements  and  Analysis  Branch, 
Coastal  Engineering  Research  Center  (CERC),  WES.  Mr.  E.  Claik  McNair, 

Jr.,  and  Dr.  LyndeU  Z.  Hales  were  Manager  and  Assistant  Manager,  respec¬ 
tively,  of  the  DRP.  Dr.  James  R.  Houston  and  Mr.  Charles  C.  Calhoun,  Jr., 
were  Director  and  Assistant  Director,  respectively,  of  CERC,  which  conducted 
the  DRP. 

At  the  time  of  publication  of  this  report.  Dr.  Robert  W.  Whalin  was  Direc¬ 
tor  of  WES.  COL  Bmce  K.  Howard,  EN,  was  Commander. 

For  further  information  concerning  this  report,  contact  Mr.  James  Rosati, 
(601)  634-2022,  or  Mr.  E.  Qaik  McNair,  Jr.,  (601)  634-2070. 


The  contents  of  this  report  are  not  to  be  used  for  advertising,  publication, 
or  promotional  purposes.  Citation  of  trade  names  does  not  constitute  an 
official  endorsement  or  approval  of  the  use  of  such  commercial  products. 


Summary 


This  report  describes  the  Silent  Inspector  system  developed  for  monitoring 
hoj^r  dredge  operations.  The  system  collects  and  records  measurements  from 
shipboard  sensors,  calculates  the  dredging  activities  being  performed  and  the 
weight  of  the  material  recovered,  and  displays  this  information  through  stan¬ 
dard  reports  and  graphical  data  displays.  Recorded  data  are  also  automatically 
backed  up  and  later  archived  to  allow  transfer  of  the  data  to  other  locations. 
The  Silent  Inspector  data  can  provide  a  permanent  record  of  the  dredging 
activity. 

TTie  system  operates  on  personal  computers  using  the  Unix  operating  sys¬ 
tem  to  allow  multitasking  operations,  and  consists  of  three  primary  com¬ 
ponents:  a  dredge-specific  software  (SDD)  component,  a  ship-based 
component  (SHIP),  and  a  shore-based  component  (SHORE).  The  DSS  collects 
sensor  data,  checks  these  data  against  acceptable  ranges,  computes  the  status  of 
the  dredging  pumps  (on/off)  and  other  equipment,  attaches  the  name  of  the 
project,  dredge,  and  contract  number  to  the  sensor  data,  and  inserts  these 
incoming  data  into  the  system’s  central  database.  SHIP  maintains  the  system’s 
central  database,  accepting  data  in  real  time  from  a  DSS.  SHIP  then  reviews 
those  data,  computes  the  present  dredging  activity  being  performed  and  the 
amount  of  material  recovered,  and  produces  reports  (trip,  daily,  job)  and  graph¬ 
ical  displays  of  the  data.  Additional  information  concerning  the  dredging 
project,  the  dredges  used,  and  location  of  the  dredging  and  disposal  areas  can 
also  be  inserted  into  the  system  database  via  the  SHIP  component.  SHORE 
differs  from  the  SHIP  component  in  that  it  does  not  receive  data  in  real  time 
from  a  DSS  unit.  Its  purpose  is  to  provide  in-office  data  review,  display,  and 
post-field  processing. 

The  system  is  built  upon  the  Sybase  relational  database  and  utilizes  client- 
server  architecture  to  interface  with  programs  and  computers  accessing  the 
database.  Once  turned  on,  the  system  operates  nearly  autonomously  in  its 
collection,  processing,  reporting,  and  archiving  of  data.  Many  additional  oper¬ 
ations,  such  as  specific  data  displays,  are  user  initiated  and  controlled.  Nearly 
all  user  controlled  activities  are  operated  using  graphical  screens  for  ease  of 
use  and  minimal  training  time.  System  security  is  maintained  through  user 
ID’S  and  password  protection. 


Described  herein  are  the  system’s  database  structure,  data  computations, 
data  flow,  system  architecture  and  interfaces,  and  software  structure.  This 
manual  is  designed  to  assist  system  engineers  in  the  upkeep  and  modiflcation 
of  the  system  and  its  components. 


1  Introduction 


Concept  of  the  Silent  Inspector  System 

The  Dredging  Operations  Silent  Inspector  System  (DOSIS),  referred  to  as 
the  Silent  Inspector,  was  created  to  be  a  tool  to  assist  Corps  dredging  inspec¬ 
tors  in  monitoring  the  performance  of  contracted  hopper  dredging  operations 
on  a  24-hr  basis.  The  Silent  Inspector  provides  automated  collection,  analy¬ 
sis,  display,  and  reporting  of  information  about  a  dredge’s  activities  which 
allow  inspectors  and  contract  administrators  to  better  assess  contractor  perfor¬ 
mance  and  adherence  to  contract  terms,  both  when  dredge  inspectors  are 
aboard  the  dredge  and  especially  when  they  are  not  aboard.  The  present  sys¬ 
tem,  described  in  this  manual,  is  designed  for  hopper  dredges  only. 

The  system  uses  state-of-the-art  computer  hardware  and  software  to  simulta¬ 
neously  measure  several  parameters  of  the  dredge’s  activities,  calculate  addi¬ 
tional  information,  such  as  the  activity  the  dredge  is  performing  and  the 
quantity  of  material  it  has  retained,  display  this  information,  automatically  pro¬ 
duce  Corps  dredging  reports,  and  provide  a  permanent  and  transferable  copy  of 
this  information.  The  system  strives  to  produce  a  factual  record  of  the 
dredge’s  activities  that  is  sufficient  for  dredging  inspectors  to  accurately  assess 
contract  performance. 

In  particular,  the  overall  functions  the  system  is  designed  to  perform  are: 

a.  Record  data  on  several  aspects  of  dredging  operations. 

b.  Properly  label  the  data  with  the  project  name,  contract  ID,  dredge 
name,  trip  (load)  number,  and  dredging  and  disposal  locations. 

c.  Compute  the  type  of  dredging  activity  occurring  aboard  the  dredge  at 
any  time  and  the  amount  of  material  recovered  in  terms  of  tons  dry 
measure  (TDM). 

d.  Automatically  provide  summaries  of  trip  (load),  daily,  and  job-to-date 
dredging  activities  on  a  basis  similar  to  reports  in  use  today. 

e.  Graphically  display  recorded  data. 
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/.  Automatically  back  up  recorded  data  daily  and  weekly. 


g.  Archive  the  data  for  transfer  to  other  Silent  Inspector  systems  and  for 
permanent  record  keeping. 

While  the  direct  purpose  of  the  system  is  to  allow  inspectors  and  contract 
administrators  to  assess  contract  performance,  use  of  the  Silent  Inspector  sys¬ 
tem  provides  the  following  additional  benefits  to  the  Corps  of  Engineers: 

a.  Measures,  records,  and  reports  dredging  information  in  a  standardized 
format  for  similar  types  of  dredges  to  allow  the  data  to  be  transferred 
easily  between  aU  Corps  of  Engineers  Districts  and  offices. 

b.  Provides  a  means  to  electronically  archive  the  data  collected  and  trans¬ 
fer  it  to  users  working  on  other  hardware  and  software  mediums. 

c.  Provides  a  graphical  display  of  collected  data  by  time  or  location. 

d.  Provides  a  Corps-generated  independent  database  of  dredging  activities 
for  use  in  settling  claims  brought  by  contractors  against  the  Corps. 

e.  Provides  flexibility  and  extendibility  to  meet  changing  system  require¬ 
ments,  and  to  meet  each  District’s  unique  system  requirements. 

/.  Allows  Corps  users  to  add  individual  features  without  destroying  the 
integrity  or  operation  of  the  basic  system. 

g.  Provides  the  Corps  a  more  accurate  assessment  of  dredging  activities, 
downtime,  and  production  rates  for  more  accurate  estimating  of  future 
project  costs  and  budgets. 


The  system  has  been  designed  to  be  easy  to  use  via  graphical  user  screens, 
is  highly  automated  so  that  it  functions  reliably,  and  noncorruptible,  so  that 
access  to  the  system  is  limited  to  approved  users,  and  the  recorded  data  cannot 
be  altered  or  manipulated. 


About  This  Manual 

To  assist  in  the  development  of  the  Silent  Inspector  system  operating 
requirements  and  standards,  a  training  and  reference  version  of  the  system  was 
developed.  This  system  is  a  specific  implementation  of  the  Silent  Inspector 
concept.  This  manual  provides  technical  infonnation  on  how  the  training  and 
reference  Silent  Inspector  system  for  hopper  dredges  is  constructed  and  func¬ 
tions.  This  manual  is  specifically  targeted  to  system  support  personnel  and 
system  engineers  and  programmers.  This  manual  does  not  describe  how  to 
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operate  the  system;  for  that  information,  the  reader  is  referred  to  the  Silent 
Inspector  User’s  Manual} 

This  manual  is  organized  into  the  following  chapters: 

a.  System  Overview:  Chapter  2  discusses  the  system’s  overall  capabilities, 
its  major  components,  its  software  modules  and  functions,  and  the 
software  standards  to  which  it  adheres. 

b.  Dredge-Specific  System:  Chapter  3  describes  the  function  and  actions 
of  the  dredge-specific  software  (DSS)  component  of  the  system,  which 
gathers  sensor  measurements  and  inputs  these  data  into  the  system 
database. 

c.  System  Database:  Chapter  4  describes  the  system’s  central  database 
structure,  tables,  data  flow,  and  controlling  programs. 

d.  System  Computations:  Chapter  5  lists  the  computations  and  provides 
the  equations  for  all  calculations  of  new  information  which  occur 
within  the  system. 

e.  System  Inteifaces:  Chapter  6  describes  the  interface  requirements  and 
formats  used  by,  and  required  for  interaction  with,  the  system. 

/.  SHIP  Software  Modules:  Chapter  7  describes  how  various  software 
modules  controlled  by  the  user  function,  once  initiated. 

g.  Stored  Procedures:  Appendix  A  is  a  listing  of  the  stored  procedures 
used  with  the  Silent  Inspector  software. 

h.  Backup  and  Archive  Script:  Appendix  B  is  a  listing  of  the  backup  and 
archive  script  for  the  Silent  Inspector  software. 

i.  Configuration  Management  Library  Structure:  Appendix  C  is  a  listing 
of  the  configuration  management  library  structure  for  the  Silent  Inspec¬ 
tor  software. 


*  Cox,  J.  M.,  Maresca,  P.,  and  Jarvela,  A.  (1995).  “Silent  Inspector  User’s  Manual,”  Instruc- 
tion  Report  DRP-95-2,  U.S.  Army  Engineer  Waterways  Experiment  Station,  Vicksburg,  MS. 
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2  System  Overview 


This  chapter  provides  an  overview  of  how  the  hopper  dredge  Silent  Inspec¬ 
tor  system  is  structured,  how  data  move  through  the  system,  where  data  are 
stored,  and  the  functions  of  the  various  software  modules. 


System  Operational  Components 

The  Training  and  Reference  Silent  Inspector  system  is  composed  of  three 
operational  units,  called  components.  These  components  are  named: 

a.  Dredge-specific  software  component  (DSS). 

b.  Ship  component  (SHIP). 

c.  Shore  component  (SHORE). 

The  central  database  and  primary  data  processing  actions  are  contained 
within  the  SHIP  component.  This  component  receives  data  in  real  time  from 
the  DSS  component,  uses  those  data  to  compute  the  dredge’s  current  activity 
(dredge  state)  and  other  information,  and  packages  those  data  into  standard 
reports  and  displays.  The  DSS  component  accesses  sensor  data  on  dredges, 
checks  that  the  data  are  within  an  acceptable  range,  and  repackages  the  data 
for  insertion  into  the  SHIP  database.  The  SHORE  component  accepts  data 
which  have  been  acquired  and  processed  by  a  SHIP  database,  and  allows  users 
to  review  and  display  previously  recorded  data,  and  regenerate  dredging 
reports  over  user-specified  time  periods.  A  more  detailed  overview  of  each 
component  is  provided  below. 


Dredge-specific  software  (DSS)  component 

The  Silent  Inspector  system’s  central  database  for  receiving  and  storing 
real-time  data  aboard  a  dredge  resides  within  the  SHIP  component.  This  data¬ 
base  is  designed  to  accept  specific  types  of  data  about  hopper  dredge  opera¬ 
tions.  In  addition,  the  SHIP  component  is  designed  to  be  identical  in  all  Silent 
Inspector  hopper  dredge  systems,  so  that  the  system  is  consistent  between  all 
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dredges.  As  each  hopper  dtedge  contains  a  different  suite  of  measurement 
sensors,  sensor  locations,  calibrations,  data  formats,  and  types  of  data  available, 
these  imique  packages  of  sensor  data  must  be  converted  into  a  standard  pack¬ 
age  of  data,  called  data  records,  and  sent  to  the  SHIP  component  in  identical 
format  and  fashion.  This  is  the  role  of  the  DSS  component.  The  specific 
functions  of  the  DSS  are  to: 

a.  Acquire  dredge  sensor  measurement  data  every  10  sec. 

b.  Determine  if  the  sensor  data  arc  within  acceptable  ranges. 

c.  Compute  additional  information  needed  by  the  SHIP  database. 

d.  Repackage  measured  and  computed  data  into  a  standard  format  (data 
record). 

e.  Attach  the  contract  ID,  project  name,  and  dredge  name  provided  by  the 
user  to  the  data  record. 

/.  Insert  the  data  into  the  SHIP  database. 

While  the  output  of  each  DSS  is  identical,  the  inputs  to  a  DSS  will  vary 
from  dredge  to  dredge;  therefore,  no  two  DSS  units  are  expected  to  operate 
internally  in  exactly  the  same  way.  This  manual  describes  the  standard  por¬ 
tions  of  the  DSS  component,  such  as  the  DSS-to-SHIP  interface,  as  well  as  the 
unique  portions  of  the  training  and  reference  DSS,  which  was  created  to  inter¬ 
act  with  the  Corps  of  Engineers  dredge  Essayons  for  purposes  of  system  devel¬ 
opment  and  testing. 


SHIP  component 

The  SHIP  component  is  the  heart  of  the  Silent  Inspector  system.  Like  the 
DSS,  it  resides  onboard  the  dredge;  however,  all  SHIP  components  are  identi¬ 
cal.  Required  measured  data  are  received  from  the  DSS  and  are  inserted  into 
the  system’s  central  database.  The  SHIP  system  then  also  performs  the 
following: 

a.  Displays  the  incoming  data  in  real  time. 

b.  Automatically  computes  and  records  the  current  dredging  operation, 
called  the  dredge  state,  as  well  as  the  amount  of  material  retained 
(TDM). 

c.  Automatically  creates  standard  trip  and  daily  reports  based  on  the 
recorded  data,  and  creates  job-to-date  reports  when  initiated  by  the  user. 

d.  Graphically  displays  any  measurement  data  contained  within  the  data¬ 
base  that  are  requested  by  the  user. 
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e.  Automatically  backs  up  and  archives  data. 

/.  Permits  the  user  to  input  information  concerning  the  dredging  project, 
dredge,  its  crew,  dredging  and  disposal  areas,  and  local  marine 
landmarics. 

TThe  above  capabilities  are  either  initiated  or  controlled  by  several  software 
modules.  These  modules  generally  allow  the  user  to  input  specific  information 
into  the  database,  display  or  review  data  within  the  database,  or  control  the 
automatic  operation  of  the  database.  The  primary  software  modules  contained 
within  the  SHIP  component,  and  their  functions,  are: 


Software  Modules 

Purpose/Function 

RT  Kernel 

Computes  dredge  state,  TDM,  computes  and  prints  stan¬ 
dard  reports,  controls  flow  of  data  through  database 

Setup 

User  entry  of  project  and  dredge  information 

Monitoring 

Displays  Incoming  data  from  DSS 

Standard  Reports 

Calculates  and  produces  trip  and  daily  reports 

Downtime 

Display  of  downtime  events,  and  user  input  of  downtime 
cause  and  comments 

Plotting 

Graphical  display  of  recorded  data  over  time  period  selected 
by  user 

Backup 

Automated  daily  and  weekly  backup  of  recorded  data,  and 
user  initiated  restoration  of  database  using  backup  files 

Archive 

Automated  archiving  of  recorded  data,  and  user  initiated 
transfer  of  archived  files 

SHORE  component 

When  data,  which  are  recorded  on  a  dredge  by  the  SHIP  component,  are  to 
be  analyzed  at  a  location  other  than  on  the  dredge,  the  data  are  transferred  to  a 
SHORE  component.  The  SHORE  component  may  reside  at  any  location,  such 
as  the  Corps  of  Engineers  District  offices.  Data  analysis  may  include  more 
detailed  review  of  the  data,  and  inter-comparison  of  data  obtained  from  mul¬ 
tiple  SHIP  units. 

The  SHORE  component  functions  quite  similar  to  SHIP,  with  the  following 
exceptions: 

•  It  operates  on  shore-based  computers. 

•  It  does  not  collect  data  in  real  time  from  a  DSS  component. 

•  It  is  able  to  input  and  review  data  sets  from  multiple  dredging  projects. 
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Software  modules  present  within  the  SHIP  component  (listed  above)  but  not 
present  or  active  within  the  SHORE  component  are: 

Software  Modules  Purpose/Function 

RT  Kernel  Computes  dredge  state,  TDM,  computes  and  prints  stan¬ 

dard  reports,  controls  flow  of  data  through  database 

Monitoring  Displays  Incoming  data  from  DSS 

Archive  User-initiated  loading  or  downloading  of  archived  files 

The  SHORE  user  interface  screens  are  identical  to  the  SHIP  user  interface 
screens  for  those  software  functions  contained  in  both  components.  Multiple 
SHIP  data  sets  can  be  input  into  SHORE.  Each  remains  unique  based  on  the 
project  name,  contract  ID,  and  dredge  name  assigned  to  the  data. 


Hardware  and  Software  Requirements 

The  Training  and  Reference  Silent  Inspector  system  for  hopper  dredges 
operates  on  the  Unix  operating  system,  and  486  type  personal  computers 
(PC’s).  The  system  software  has  been  designed  to  require  minimal  or  no  user 
knowledge  of  the  Unix  operating  system  or  commercial  software  packages 
utilized  within  the  system.  User  interactions  with  the  system  are  via  a  graph¬ 
ical  user  interface  that  allows  easy  setup,  operation,  and  data  review.  Cur¬ 
rently  the  system  utilizes  the  hardware  and  software  listed  below. 


System  hardware 

The  Silent  Inspector  hopper  dredge  system  is  designed  to  be  used  on  PC’s, 
because  they  are  commonly  used  throughout  Corps  of  Engineers  Districts. 
Communication  between  components,  if  the  components  reside  on  separate 
computers,  is  via  Ethernet  when  the  component  computers  are  cabled  directly 
together.  The  following  computer  hardware  is  necessary  for  each  component 
to  ensure  proper  operation: 


Hardware 

DSS 

SHIP 

SHORE 

486  PC  with  minimum  of  3  3 -MHz  clock, 
VGA  graphics,  standard  monitor, 

500-MB  haid  drive,  32-MB  RAM 

X 

X 

X 

Ethernet  link 

X 

X 

Postscript  laser  printer 

X 

X 

Streaming  tape  drive  and  tapes 

X 

X 

Uninterruptable  power  supply  (UPS) 

X 

X 
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System  software 


The  Silent  Inspector  system  was  developed  using  several  commercial  soft¬ 
ware  packages.  These  packages  provide  the  graphical  user  screens  and  data¬ 
base  engine  within  the  system.  Consequently,  each  component  of  the  system 
needs  to  access  these  commercial  packages  to  operate  properly.  The  software 
packages  listed  below  must  be  purchased  and  installed  on  the  DSS,  SHIP,  and 
SHORE  computers  for  the  system  to  work. 

Software 

SCO  Unix  with  open  desktop 
SL-GMS 

Sybase  relational  database  management  system  (DBMS)  (2-8  users) 

System-specific  software  is  used  to  tie  specific  user  actions  on  the  graphical 
user  interface  screens  to  system  actions  and  to  control  the  flow  of  data  through 
the  database  and  display  screens.  In  the  Training  and  Reference  Silent  Inspec¬ 
tor  system,  this  system-specific  software  is  written  primarily  in  the  ADA  soft¬ 
ware  language.  Some  limited  commands  also  are  programmed  within  Unix 
script.  Database  stored  procedures  utilize  Sybase  commands  and  script. 


System  Development  Standards 

The  following  standards  were  used  in  the  development  of  the  Training  and 
Reference  Silent  Inspector  System.  All  implementations  of  the  Silent  Inspector 
system  for  hopper  dredges  should  adhere  to  these  standards.  Some  of  these 
standards  are  recognized  industry  standards,  and  some  were  developed  as  part 
of  the  Silent  Inspector  development  program  to  ensure  common  capabilities 
between  all  Silent  Inspector  systems,  regardless  of  their  specific 
implementation  conditions. 


industry  standards 

Operating  System: 

IEEE  Posix  1003.1  and  FIPS  151-1 

Database  Management  System: 

SQL  (FIPS  127,  ANS  X3. 135-1986) 
ISO-RDA  (Remote  Database  Access) 

Graphics  Data  Interchange: 

CGM  (FIPS  128) 

IGES 

PDES  (NBSIR  88-3813) 

Postscript 
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Network  Services: 

OSI  GOSIP  (ANSI  X3T5  and  FIPS  146) 

NFS  (IEEE  Posix  1003.8) 

User  Interface: 

X  Window  System  -  XI  1.6  (FIPS  158) 

OSF/Motif 

Microsoft’s  Presentation  Manager 

Connectivity: 

TCP/IP 

Ethernet  (IEEE  802.3) 

Applications  Portability  Profile: 

FIPS  151  (with  conformance  to  extended  Posix,  SQL,  OSI,  NFS, 
X- Windows,  C  and  other  languages) 

Program  Languages: 

C  (ANSI  X3J11  and  X3. 159- 1989) 

FORTRAN  (FIPS  069-1  and  ANSI  X3J3,  ANS  X3.9-1978) 
ADA  (FBPS  119,  ISO  8652,  ANSI  MIL  18115A) 

PASCAL  (FIPS  109,  ANSI  S3I9,  ISO  7185-1983  Level  1) 


Silent  Inspector  specific  standards 

Interfaces: 

SHIP  database  input/DSS  output 

Reports: 

Trip 

Daily 

Job-to-date 

Computations: 

TDM 

Dredge  state 

The  specific  requirements  of  each  of  the  system-specific  standards  are 
described  in  detail  within  later  chapters  in  this  manual. 
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3  Dredge-Specific  System 


The  dredge-specific  system  (DSS)  component  of  the  Silent  Inspector  system 
is  designed  to  receive  a  variety  of  measurements  from  sensors  aboard  hopper 
dredges,  to  formulate  from  these  sensor  measurements  a  common  (identical) 
package  of  data  required  by  the  SHIP  component  of  the  system,  and  to  insert 
this  package  of  data  into  the  SHIP  database  at  regular  (10-sec)  intervals.  To 
perform  this  function,  the  DSS  computes  some  data  values  which  are  not 
directly  measured.  The  DSS  also  compares  each  measured  or  calculated  data 
value  to  an,  acceptable  range  for  that  data  value  and  attaches  a  data  status  flag 
to  the  data  within  the  SHIP  database. 

Because  no  two  hopper  dredges  are  expected  to  have  identical  sensor  infor¬ 
mation  available  or  to  necessarily  input  the  available  measurements  into  the 
DSS  in  identical  fashion  (RS232,  RS422,  digitized  voltages,  etc.),  each  DSS  is 
expected  to  differ  in  how  it  handles  accepting  sensor  data,  internal  data  com¬ 
putations,  acceptable  data  ranges,  necessary  operator  inputs,  and  data  display. 
All  DSS  components  are  expected  to  be  identical  in  terms  of  some  operator 
inputs,  data  status  checking  procedures,  content  and  format  of  the  data  sent  to 
the  SHIP  database,  and  how  it  inserts  the  data  into  the  SHIP  database  (DSS-to- 
SHIP  interface). 

The  specific  tasks  the  DSS  performs  are  listed  below: 

a.  Handling  of  operator  inputs. 

b.  Reading  of  required  sensor  data. 

c.  Conversion  of  the  sensor  data  from  its  input  format  to  the  format 
required  for  insertion  into  the  SHIP  database. 

d.  Computation,  based  on  the  sensor  data,  of  additional  data  required  to  be 
inserted  into  the  SHIP  database. 

e.  Assignment  of  status  values  to  applicable  sensor  and  computed  data 
values. 

/.  Display  of  the  sensor  and  computed  measurements  and  status  values. 
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g.  Insertion  of  the  sensor  and  computed  data  and  associated  status  values 
into  the  SHIP  database. 

How  each  of  these  tasks  is  performed  within  the  training  and  reference  DSS 
is  described  in  detail  in  the  following  sections. 


Operator  Inputs 

All  DSS  units  require  the  user  to  input  three  pieces  of  information  about  a 
project:  the  contract  ID,  project  name,  and  dredge  name.  Each  item  may  be 
up  to  32  characters  in  length.  This  information  is  entered  on  the  DSS  Entry 
Panel  screen  (see  User’s  Manual,  Figure  4.4).^  The  contract  ID,  project 
name,  and  dredge  name  are  inserted  into  the  SHIP  database  with  every  sensor 
input  record  to  identify  the  source  of  the  data. 

The  training  and  reference  DSS  also  allows  the  user  to  select  or  control  two 
other  items  for  use  in  testing  the  system.  These  are:  (a)  the  source  of 
incoming  sensor  data  (either  real-time  from  a  dredge,  or  from  a  pre-recorded 
computer  file)  and  (b)  the  time  associated  with  the  incoming  data  when  they 
are  sent  on  to  the  SHIP  database. 

To  select  a  data  file  as  the  source  of  incoming  data,  the  user  must  enter 
computer  drive,  directory,  subdirectory,  and  file  name  within  the  data  source 
box  on  the  DSS  Entry  Screen.  The  DSS  wiU  then  access  and  read  the  data 
from  that  file.  If  no  entry  is  made  within  the  data  source  box,  the  DSS 
assumes  the  sensor  data  are  entering  the  DSS  through  an  RS232  port  in 
real-time. 

If  a  file  is  being  used  as  the  input  source,  the  sensor  data  read  from  the  file 
are  processed  and  inserted  into  the  database.  Each  set  of  sensor  data  has  an 
original  time  tag  associated  with  it.  For  testing  purposes,  it  is  sometimes 
useful  to  set  a  data  rate  different  from  that  at  which  the  sensor  data  were 
originally  collected.  This  can  be  done  by  the  operator  by  clicking  on  the 
user-defined  timer  input  button  and  specifying  a  time  interval  between  meas¬ 
urements.  A  slider  bar  is  displayed  that  permits  the  operator  to  set  the  data 
interval  in  seconds. 

When  a  user-defined  time  interval  is  set,  the  original  time  tag  associated 
with  the  first  set  of  measurements  is  used  to  establish  the  dateAime  of  the  first 
measurement  set,  and  then  all  other  date/time  values  associated  with  the 
remaining  measurements  in  the  file  are  computed  by  the  DSS  using  the  user- 
selected  time  interval.  The  time  tag  for  each  successive  set  of  measurements  is 
determined  by  adding  the  user-defined  time  interval  to  the  time  tag  computed 
for  the  immediately  preceding  measurement  set.  The  original  date/time  values 


1  Ibid. 
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are  not  altered  within  the  pre-recorded  data  file;  however,  the  newly  computed 
dateAime  values  are  inserted  along  with  the  data  into  the  SHIP  database. 
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Reading  Sensor  Data 

The  training  and  reference  DSS  was  first  tested  on  the  Corps  of  Engineers 
dredge  Essayons;  therefore,  the  sensor  data  input  format  is  specifically  tuned  to 
this  dredge  and  the  output  of  a  data  logging  computer  presently  operating 
aboard  the  dredge.  The  following  sensor  data  are  currently  accepted  into  the 
training  and  reference  DSS.  This  same  suite  of  sensor  data  should  be  input 
into  aU  DSS  units;  however,  it  is  imderstood  that  on  some  hopper  dredges  this 
suite  of  sensor  measurements  may  not  be  currently  available. 


Data  Element 

Units 

Date 

Local  time 

Time 

Seconds,  from  midnight  local  time 

RMS  error  (of  ship’s  position) 

feet 

X  location 

feet 

Y  location 

feet 

Forward  draft  (of  ship) 

feet 

Aft  draft  (of  ship) 

feet 

Tide  elevation 

feet  (relative  to  MLLW) 

Port  drag  arm  velocity 

feet/sec 

Port  drag  arm  density 

g/i 

Starboard  drag  arm  velocity 

feet/sec 

Starboard  drag  arm  density 

g/i 

Port  gimbal  depth 

feet 

Starboard  gimbal  depth 

feet 

Port  draghead  depth 

feet 

Starboard  draghead  depth 

feet 

Heading  (of  ship  from  Gyro) 

degrees  True 

Course  (of  ship) 

degrees  True 

Water  deptii  (below  ship) 

feet 

Speed  (of  ship  over  ground) 

knots 

Ship  weight-hopper  doors  open 

long  tons 

Ship  weight-hopper  doors  dosed 

long  tons 

Ullage  (meter  #1) 

feet 

Ullage  (meter  #2) 

feet 

Ullage  (meter  #3) 

feet 

Ullage  (meter  #4) 

feet 

Hopper  door  status 

open/dosed 

The  DSS  is  capable  of  accepting  the  above  sensor  data  as  a  continuous 
input  stream  through  an  RS232  input  port  or  from  a  pre-recorded  ASCII  text 
file.  The  latter  mode  is  normally  used  for  testing  the  training  and  reference 
Silent  Inspector  system,  and  this  capability  is  not  expected  to  be  included  in 
standard  systems. 

Data  received  through  the  RS232  port  are  in  binary  format  and  are  nor¬ 
mally  received  from  another  computer.  When  real-time  sensor  data  are 
received  via  the  RS232  serial  port,  the  DSS  divides  the  data  stream  up  into 
records  by  treating  some  number  of  contiguous  bytes  as  a  record.  In  the  train¬ 
ing  and  reference  DSS,  this  quantity  is  127  bytes,  with  a  record  being  defined 
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as  a  set  of  sensor  measurements  all  associated  with  a  single  time  tag.  The 
format  and  position  of  each  sensor  measurement  value  within  each  record  are 
described  in  Chapter  6  (“System  Interfaces”)  of  this  manual.  The  input  data 
stream  is  first  broken  into  individual  records,  which  are  collected  in  a  buffer. 
Next,  the  sensor  values  within  each  record  are  extracted  and  placed  within  a 
database  structure,  defined  within  the  DSS  system  code.  The  contract  ID  num¬ 
ber,  project  name,  and  dredge  name  for  this  project,  previously  entered  into  the 
DSS  by  the  operator,  are  then  attached  to  each  data  record  stored  in  the 
DSS  database  structure.  Next,  the  sensor  values  in  a  record  are  used  to  com¬ 
pute  some  additional  data  values,  and  all  values  are  cross-checked  against  a 
limits  table  to  assign  a  data  status  flag  to  several  of  the  data  values.  These 
computations  are  listed  below.  The  newly  computed  values  and  status  flags 
are  then  attached  to  the  data  record  in  the  DSS  database  structure.  Each  data 
record  is  then  inserted  into  the  SHIP  database. 

If  the  input  source  is  a  data  file,  each  record  is  read  as  a  string  of  ASCII 
text.  The  fields  that  represent  the  sensor  measurements  are  extracted  from  the 
string  and  placed  within  the  DSS  database  structure.  Again,  the  contract  ID 
number,  project  name,  and  dredge  name  for  this  project,  previously  entered 
into  the  DSS  by  the  operator,  are  attached  to  each  data  record;  and  the  sensor 
values  in  the  record  are  used  to  compute  additional  data  values  and  data  status 
flags.  The  newly  computed  values  and  status  flags  are  then  attached  to  the 
data  record  in  the  DSS  database  structure.  In  addition,  the  time  previously 
attached  to  the  data  record  is  disregarded,  except  for  the  time  of  the  first  data 
record  read.  All  subsequent  times  attached  to  the  incoming  records  are  based 
upon  the  time  of  the  first  data  record  and  the  time  interval  between  data 
records  selected  by  the  operator  on  the  DSS  control  panel  screen.  This  feature 
allows  for  more  rapid  testing  of  the  training  and  reference  Silent  Inspector 
system.  After  a  new  time  is  attached  to  the  record,  the  data  record  is  then 
inserted  into  the  SHIP  database. 

The  DSS  accepts  data  records  from  either  the  RS232  port  or  a  pre-recorded 
data  file  as  fast  as  the  data  logging  computer  can  send  them  and  the  DSS  can 
process  these  data  and  send  them  on  to  the  SHIP  database.  The  maximum 
input  speed  for  the  DSS  is  faster  than  one  data  record  per  second.  In  the  case 
of  the  Essayons,  the  data  logging  computer  sends  the  DSS  a  new  data  record 
every  10  sec.  Currently  there  is  no  provision  for  error  checking  or  synchro¬ 
nization,  should  data  be  lost  in  transmission. 


Computation  of  Additional  Data  Values 

The  SHIP  database  also  requires  as  input  some  data  types  that  are  not  pro¬ 
vided  by  sensors  aboard  the  Essayons.  Likewise,  it  is  anticipated  that  sensors 
aboard  other  hopper  dredges  may  not  provide  the  fuU  suite  of  measurements 
necessary  for  insertion  into  the  SHIP  database.  Where  possible,  the  DSS  also 
must  compute  the  additional  data  needed  by  the  SHIP  database  based  on  the 
available  sensor  data.  The  following  computed  data  are  generated  within  the 
training  and  reference  DSS; 
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Computed  Data  Type 


Computed  From 


Average  hopper  level  forward 
Average  hopper  level  aft 
Average  hopper  level 
Hopper  volume 

Port/Stbd  pumps  oo/off 

Port/Stbd  material  recovery  true/false 

Pump  out  on/off 


Two  forward  ullage  sensor  readings 
Two  aft  ullage  sensor  readings 
Average  forward  and  aft  hopper  level  values 
Average  hopper  ullage  and  hopper  volume 
curve^equations 

Port  and  starboard  draghead  velocities 
Port  and  starboard  draghead  densities 
Pump-out  velocity  (not  provided  on  Essayons) 


The  equations  for  each  of  these  computations  are  provided  in  Chapter  5  of 
this  manual. 


Assigning  Status  Vaiues 


The  DSS  provides  the  first  level  of  data  QA/QC  for  the  Silent  Inspector 
system.  This  process  is  performed  by  comparing  each  sensor  or  computed 
data  value  to  an  acceptable  range  for  that  data  value.  The  status  values  that 
can  be  assigned  are: 


Status 

Abbr. 

Meaning 

ACCEPTABLE 

OK 

Sensor  measurement  is  within  acceptable  limits 

OUT  OF_RANGE_LOW 

LO 

Sensor  measurement  is  out-of-range  low 

OUT  OF  RANGE  HIGH 

HI 

Sensor  measurement  is  out-of-range  high 

MISSING 

NO 

Sensor  measurement  is  missing 

Minimum  and  maximum  acceptable  values  for  each  type  of  data  are  read 
from  a  file  named  RANGE.DAT  stored  within  the  DSS.  This  file  is  an  ASCII 
text  file  that  may  be  edited  to  adjust  the  values  for  each  type  of  data.  The  user 
is  not  intended  to  have  access  to  this  table.  Values  in  this  table  must  be 
entered  or  changed  by  a  systems  engineer.  The  current  ranges  established  for 
the  training  and  reference  DSS  for  operation  aboard  the  Essayons  are: 


Sensor 

Measurement 

RMS_ERROR 

X_COORDINATE 

Y_COORDlNATE 

FORWARD_DRAFT 

AFT^DRAFT 

TIDE 

PORT_DRAGARM_VELOCITY 

PORT^DRAGARM^DENSITY 

STBD^DRAGARM^VELOCITY 

STBD^DRAGARM^DENSITY 

PORT_GIMBAL_DEPTH 

STBD_GIMBAL_DEPTH 

PORT_DRAGHEAD_DEPTH 

STBD_DRAGHEAD_DEPTH 

HEADING 

COURSE 

GROUND^SPEED 


Lower 

Upper 

Bound 

Bound 

0.0 

32.9 

0.0 

9_999_998.0 

0.0 

9  999_998.0 

10.0 

35.0 

15.0 

37.0 

-5.0 

35.0 

0.0 

50.0 

1.0 

3.0 

0.0 

50.0 

1.0 

3.0 

0.0 

90.0 

0.0 

90.0 

-20.0 

90.0 

-20.0 

90.0 

0.0 

359.9 

0.0 

359.9 

0.0 

16.0 
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WATER_DEPTH  0.0  90.0 

HOPPER.ULLAGE  0.0  50.0 

If  a  measurement  value  exceeds  its  upper  bound,  its  corresponding  status 
value  is  set  to  OlJT_OF_RANGE_HIGH  (HI).  Similarly,  if  it  is  less  than  its 
lower  bound,  its  status  value  is  set  to  01JT_0F_RANGE_L0W  (LO).  If  a 
measurement  is  missing,  the  status  MISSING  (NO)  is  assigned  to  it.  Other¬ 
wise,  the  measurement  is  deemed  acceptable,  and  its  status  value  is  set  to 
ACCEPTABLE  (OK).  These  status  values  are  stored  within  the  DSS  in  the 
DSS  database  stmcture;  however,  they  are  inserted  into  the  SHIP  as  integer 
values  from  0  to  3  as  shown  below. 

Status  Database  Value 

ACCEPTABLE  0 

OUT_OF_RANGE_LOW  1 

OUT_OF_RANGE_HIGH  2 

MISSING  3 

The  data  status  values  are  used  to  color  code  the  display  of  the  data  values 
within  both  the  DSS  and  the  SHIP  components.  In  addition,  the  status  values 
are  also  used  in  determining  which  data  are  acceptable  to  use  in  some  compu¬ 
tations  within  the  SHIP  component. 


Data  Display 

The  Training  and  Reference  DSS  displays  on  its  control  panel  screen  the 
sensor  data  being  inserted  into  the  SHIP  database  during  processing.  Each 
sensor  value  is  displayed  with  a  background  color  that  indicates  its  associated 
status  value.  These  are  the  data  which  are  being  inserted  into  the  SHIP  data¬ 
base.  The  “Remaining”  box  shows  the  time  remaining  until  the  next  data  set, 
which  occurs  at  10-sec  intervals. 

If  the  DSS  is  receiving  data,  but  the  SHIP  component  is  not  operational 
and/or  otherwise  imprepared  to  receive  data  fiom  the  DSS,  the  DSS  will 
attempt  to  open  the  SHIP  database  and  insert  data  records,  but  will  be  unable 
to  do  so.  If  the  DSS  continues  to  try  and  open  the  SHIP  database  but  is 
unsuccessful  for  approximately  1  min,  the  DSS  program  will  then  terminate 
itself,  in  which  case  it  will  need  to  be  restarted  after  the  SHIP  database  comes 
on-line. 


Data  Manipulation  for  System  Testing 

The  training  and  reference  DSS  has  a  unique  feature  which  will  not  be 
present  on  any  standard  operational  DSS  units.  The  puipose  of  this  feature  is 
to  allow  for  testing  of  the  DOSIS  system  during  its  development  so  as  to  pre¬ 
vent  breakdown  or  corruption  of  the  system  by  unacceptable  or  missing  data. 


Chapter  3  Dredge-Specific  System 


15 


This  feature  allows  false  values  or  no  data  to  be  inserted  into  the  SHIP  data¬ 
base  for  each  data  value  displayed  on  the  DSS  data  monitoring  screen. 

Beside  each  data  value  displayed  on  the  DSS  screen  is  a  set  of  four  buttons 
marked  OK,  LO,  HI,  and  NO.  By  clicking  on  any  one  of  these  buttons,  the 
operator  can  change  the  status  value  associated  with  the  corresponding  sensor 
measurement.  Oicking  on  a  status  button  performs  the  following:  (a)  it 
changes  the  actual  data  value  that  is  inserted  into  the  SHIP  database,  as  well  as 
the  status  value  associated  with  it;  and  (b)  it  changes  the  background  color 
used  to  display  the  measurement  value  on  the  DSS  screen  to  match  the  value’s 
status.  If  the  operator  changes  the  status  of  a  measurement  to  LO,  the  meas¬ 
urement  value  ftat  is  inserted  into  the  SHIP  database  is  set  to  the  minimum 
value  of  its  acceptable  range,  obtained  from  the  RANGEJDAT  table,  minus 
0.1.  If  the  operator  changes  the  status  of  a  measurement  to  HI,  the  measure¬ 
ment  value  that  is  inserted  into  the  database  is  set  to  the  maximum  value  of  its 
acceptable  range  plus  0.1.  If  the  status  is  changed  to  NO,  no  value  for  that 
data  type  will  be  inserted  into  the  SHIP  database,  and  a  MISSING  status  value 
will  be  inserted.  Changing  the  status  back  to  OK  allows  the  incoming  or 
recorded  value  entering  the  DSS  to  again  be  inserted  into  the  SHIP  database. 

It  diould  be  noted  that  the  actual  incoming  or  recorded  data  values  entering 
the  DSS  may  also  be  out  of  acceptable  data  ranges.  In  these  cases,  when  OK 
is  pushed,  the  actual  out-of-range  data  value  and  the  DSS-assigned  status  value 
will  be  entered  into  the  SHIP  database.  The  LO,  HI,  and  NO  buttons  on  the 
DSS  data  display  screens  are  therefore  data  override  buttons.  The  status  and 
data  values  inserted  into  the  SHIP  database  remain  changed  for  that  data  type 
imtil  another  button  associated  with  the  measurement  is  clicked. 


Inserting  Data  into  the  SHIP  Database 

Once  the  DSS  database  structure  containing  the  converted  sensor  measure¬ 
ment,  calculated  values,  and  data  status  values  has  been  created,  the  informa¬ 
tion  is  inserted  into  the  SHIP  database.  The  DSS  actively  seeks  to  insert  data 
into  a  SHIP  database  whenever  the  DSS  is  operating  and  the  control  panel 
screen  is  displayed.  If  a  SHIP  component  is  on-line  at  this  time,  new  data 
records  will  be  inserted  into  the  SHIP  database  as  quickly  as  the  DSS  can 
receive  and  process  them.  Presently  this  capability  is  faster  than  one  record 
per  second;  however,  aboard  the  Essayons,  the  ship’s  data  logging  computer 
sends  the  DSS  data  records  every  10  sec;  therefore,  data  are  inserted  into  the 
SHIP  database  at  the  same  frequency. 

Data  insertion  into  the  SHIP  database  is  performed  by  the  DSS  using  a 
database  interface  program  named  Database.  Activating  the  interface  calls  a 
stored  procedure,  named  Insert _Dredging_Data,  which  resides  within  the 
Sybase  (SHIP)  database.  This  stored  procedure  transfers  the  contents  of  the 
DSS  database  structure  to  the  SHIP  database  and  stores  them  within  the 
Dredging_Data  table. 
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For  more  information  concerning  this  DSS-to-SHIP  database  interface,  see 
Chapter  6  (“System  Interfaces”)  within  this  manual.  A  complete  description  of 
the  SHIP  database  tables,  their  content,  and  structure  is  contained  within  Chap¬ 
ter  4  (“System  Database”)  of  this  manual. 
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4  System  Database 


Database  Engine 

The  Silent  Inspector  system’s  central  database  resides  within  the  SHIP  and 
SHORE  components.  The  database  structure  in  each  component  is  identical. 

The  system’s  database  is  built  and  accessed  with  the  Sybase  relational 
DBMS,  which  is  commercially  available  for  the  Unix  operating  system.  This 
is  the  database  engine  around  which  the  Silent  Inspector  system  has  been  built. 
The  Sybase  DBMS  worics  on  a  client-server  basis  with  all  programs  with 
which  it  interacts.  The  database  is  designed  so  that  multiple  functions  may 
(and  do)  occur  simultaneously.  Such  functions  include: 

Insertion  of  data  into  the  database  by  the  DSS 
Displaying  the  newly  inserted  data  for  the  user 

Calculating  additional  data,  such  as  TDM  and  dredge  state,  from  inserted  data 
Copying  data  into  other  appropriate  database  tables 

Calculating/summing  the  time  certain  dredge  activities  occur  over  a  load,  day,  or  project 
Displaying  recorded  data  as  requested  by  the  user 
Conducting  portions  of  the  data  backup  and  archiving  functions 


This  chapter  describes  how  the  Sybase  DBMS  has  been  specifically  struc¬ 
tured  to  perform  the  Silent  Inspector  operations. 


Database  Structure 

The  SHIP  database  consists  of  a  number  of  data  tables  and  stored  proce¬ 
dures.  Two  types  of  tables  exist  within  the  database:  user  tables  and  system 
tables.  User  tables  are  those  tables  which  accept  or  handle  either  information 
input  by  the  user  through  the  system’s  setup  function,  or  sensor  and  calculated 
data  and  data  status  values  inserted  by  the  DSS  or  calculated  within  the  SHIP 
component.  System  tables  are  ones  that  are  built,  updated,  and  maintained 
automatically  by  Sybase.  They  contain  infonnation  on  the  data  contained 
within  the  DBMS.  For  example,  there  is  a  system  table  that  contains  informa¬ 
tion  about  all  of  the  tables,  both  user  and  system,  known  to  Sybase.  Stored 
procedures  are  essentially  Sybase  subroutines  stored  within  the  DBMS  which 
are  called  by  the  system’s  central  program  code  to  perform  certain  operations 
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on  the  database.  The  central  program  code,  which  controls  the  automatic  pro¬ 
cessing  of  the  newly  inserted  data  and  activates  the  necessary  subroutines  and 
stored  procedures  to  calculate  additional  parameters  (such  as  the  load  number, 
TDM,  and  the  dredge  state),  store  the  newly  computed  values,  and  trigger 
automatic  reports,  is  called  the  real  time  kernel  (RT  kernel). 

There  are  currently  21  user  tables,  13  system  tables,  and  21  stored  proce¬ 
dures  within  version  1.0  of  the  SHIP  database. 


Data  Flow  Overview 

Figure  1  provides  an  overview  of  the  movement  of  data  through  the  Silent 
Inspector  system.  The  system  has  four  primary  data  input  or  transfer  inter¬ 
faces,  identified  in  Figure  1  with  the  letters  a,  b,  c,  and  d.  Interfaces  a  and  c 
are  between  computers,  whereas  interfaces  b  and  d  are  user  interactions  with 
the  DSS  and  SHIP  components  which  allow  the  user  to  input  data  on  certain 
parameters  into  the  system  via  graphical  user  interface  screens  within  the  DSS 
data  entry  panel,  and  the  SHIP  setup  module.  The  output  of  data  contained 
within  the  database  user  tables  to  a  SHORE  component  using  the  system’s 
archive  software  module  is  not  depicted.  The  parameters  which  are  transferred 
over  the  computer  interfaces  (a  and  c)  and  specifications  for  those  interfaces, 
are  described  in  detail  in  Chapter  6,  “System  Interfaces.’’ 

In  Figure  1,  rectangles  with  curved  ends  represent  user  tables  within  the 
database,  rectangles  with  pointed  ends  represent  software  modules,  true  rectan¬ 
gles  within  the  SHIP  component  box  represent  computations  or  actions  per¬ 
formed  by  RT  Kernel,  and  rectangles  with  wavy  bottoms  represent  reports  or 
graphical  displays.  Diamonds  within  the  DSS  box  indicate  computations 
occurring  within  the  DSS.  Note  that  the  user  must  enter  much  of  the  project 
and  dredge-related  information  via  the  Setup  module,  whereas  the  measured 
sensor  data  come  from  the  DSS.  RT  Kernel  is  the  systems  central  software 
program  which  controls  the  processing  and  routing  of  all  incoming  data.  The 
flow  of  data  through  the  user  tables  can  be  traced  in  more  detail  using  Table  1 
contained  within  the  next  section,  “User  Tables.” 


User  Tables 

Entries  into  the  user  tables  come  from  one  of  three  main  sources:  the  user 
through  the  setup  or  downtime  modules,  insertion  by  the  DSS  (Predging_Data 
table  only),  or  from  computations  or  data  transfers  controlled  within  RT  Ker¬ 
nel.  Data  values  contained  within  the  tables  are  called  data  elements  herein. 
Each  table  can  be  thought  of  as  a  spreadsheet,  where  each  data  element  is  a 
column  within  the  spreadsheet,  and  each  new  entry  of  values  for  the  data  ele¬ 
ments  fills  a  row.  Each  row  represents  data  associated  with  some  time  or 
event  (such  as  a  change  in  the  dredging  state).  The  user  table  names,  type  of 
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Figure  1 .  Overview  of  data  flow  within  DOSIS 


data  in  their  contents,  and  primary  data  input  sources  are  summarized  as 
follows: 


Table  Name 

Table  Contents 

Input  Source 

Crewmember 

Names,  rank,  and  ID 

Setup  module 

DisposaLArea 

Names,  boundary  coordinates 

Setup  module 

District 

Names,  abbreviations 

Setup  module 

Dredge 

Vessel  information 

Setup  module 

Landmark 

Names  and  coordinates 

Setup  module 

Location 

Name 

Setup  module 

Project 

Names,  project  information 

Setup  module 

Station 

Dredging  area  names,  boundary  coordinates 

Setup  module 

Dredging_Data 

Measured  data  and  data  status 

DSS,  RT  Kernel 

Dredge_Crew 

Assigns  crewmember  to  project  and  dredge 

RT  Kernel 

Downtime 

Downtime  events  and  causes/annotation 

RT  Kernel/Downtime 
module 

Load_DisposaLArea 

Assigns  a  trip  (load)  to  a  disposal  area 

RT  Kernel 

Load_Station 

Assigns  a  trip  (load)  to  a  dredging  area 

RT  Kernel 

Load_Table 

Trip  report  summary  information 

RT  Kernel 

Location_Station 

Assigns  a  location  to  a  dredging  area 

RT  Kernel 

Project__DisposaLArea 

Assigns  a  disposal  area  to  a  project 

RT  Kernel 

Pro]ect_Dredge 

Assigns  a  dredge  to  a  project,  sets  limits 

RT  Kernel 

ProjecLLandmark 

Assigns  a  landmark  to  a  project 

RT  Kernel 

Project_Station 

Assigns  a  dredging  area  (station)  to  a  project 

RT  Kernel 

Project  Summary 

Job-to-date  report  information 

Job  Report  module 

State 

Trip  data  for  whenever  a  state  change  occurs 

RT  Kernel 

The  individual  data  elements  contained  within  each  user  table  are  shown  in 
Table  1  on  the  following  pages.  Shown  in  this  table  are  the  user  table  name, 
purpose,  specific  data  elements  contained  within  each  table,  units  required  for 
the  data  elements,  maximum  character  length,  null  condition,  input  source,  and 
output  destinations. 

The  input  source  listed  in  these  user  tables  is  the  location  from  which  the 
data  value  or  information  for  each  data  element  is  obtained  when  it  is  inserted 
into  that  particular  table.  For  instance,  the  Dredge  (name).  Project  (name),  and 
Contract  ID  are  initially  inserted  into  the  DSS  component  of  the  system  by  the 
user.  The  DSS  inserts  this  information,  along  with  required  sensor  data  and 
status  values,  into  the  Dredgmg_Data  table  within  the  SHIP  database;  there¬ 
fore,  the  DSS  is  the  source  of  these  values  for  that  table.  These  values  are 
then  distributed  (copied)  to  12  other  tables  when  values  for  other  data  elements 
are  also  inserted  into  those  tables.  The  Dredging_Data  table,  or  another  table, 
then  becomes  the  input  source  for  these  data  elements.  When  the  user  is  the 
input  source  via  the  setup  or  downtime  modules,  those  modules  are  listed 
under  the  input  source  column.  RT  kernel  is  the  source  of  values  computed 
within  the  SHIP  component. 

While  values  for  each  data  element  can  only  have  one  input  source  from 
which  they  are  inserted  into  a  user  table,  the  values  within  a  user  table  may  be 
sent  or  copied  to  multiple  destinations.  The  Dredge  (name).  Project  (name), 
and  Contract  ID  data  elements  within  the  Dredging _Data  table  are  good  exam¬ 
ples  of  this.  Each  is  sent  from  the  Dredging_Data  table  to  several  other 
tables.  These  three  data  elements  make  up  the  unique  identifier  for  recalling 
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PROJECT  (name)  text  32  no  Dredging_Data  None 

DREDGE  (name)  text  32  no  Dredging_Data  None 
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OPPOSING_NATURAL_.ELEMENTS_TIME  minutes  8  no  RT  Kernel  Job  Report 
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the  data  related  to  any  specific  project.  RT  Kernel  controls  this  movement  or 
flow  of  data  between  the  user  tables. 


System  Tables 

The  second  type  of  tables  within  the  SHIP  database  are  called  system 
tables.  As  mentioned  before,  system  tables  are  ones  that  are  built,  updated, 
and  maintained  automatically  by  Sybase.  Neither  the  user  nor  the  system’s 
Ada  code  directly  accesses  or  modifies  the  contents  of  the  System  tables. 
These  tables  contain  “meta-data,”  which  are  data  about  the  data  or  tables 
within  the  DBMS.  The  system  tables  presently  contained  within  the  database 
are: 


Table  Name 

sysalte  mates 

syscolumns 

syscomments 

sysdepends 

sysindexes 

syskeys 

sy  slogs 

sysobjects 

sysprocedures 

sysprotects 

syssegments 

systypes 

sysusers 

A  complete  description  of  aU  the  system  tables  and  their  purpose  is  con¬ 
tained  within  the  Sybase  DBMS  manuals. 


Stored  Procedures 

While  RT  Kernel  controls  the  overall  flow  of  data  between  the  user  tables, 
the  programs  which  perform  the  actual  input,  retrieval,  or  updating  of  data 
within  the  user  tables  are  called  stored  procedures.  These  procedures  are 
essentially  Sybase  subroutines  called  by  RT  Kernel  or  other  software  modules, 
such  as  the  DSS,  when  it  inputs  data  into  the  Dredging_Data  table  in  the 
SHIP  database.  When  invoked  by  name,  Sybase  fetches  the  appropriate  stored 
procedure  and  executes  the  operations  therein  independent  from  and  without 
intervention  by  the  calling  program.  Input  parameters  are  passed  to  the  stored 
procedure  when  it  is  invoked,  and  output  parameters  are  returned  by  the  stored 
procedure  when  it  completes  its  processing.  The  procedures  are  stored  within 
the  Sybase  DBMS.  These  procedures,  while  written  specific  to  the  Silent 
Inspector  system,  were  developed  under  the  same  protocols  as  standard  Sybase 
stored  procedures. 

The  stored  procedures  perform  one  of  the  following  three  operations: 
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INSERT:  Input  data  into  a  user  table  in  the  database. 

SELECT:  Retrieve  data  from  a  user  table  in  the  database. 

UPDATE:  Update  data  within  a  user  table  in  the  database. 

There  are  21  stored  procedures  within  the  SHIP  database.  The  name  and 
purpose  of  each  procedure  are  listed  below: 

Procedure  Name  Procedure  Purpose 

iNSERT_DOWNTlME_DATA  Insert  a  downtime  event  into  the  Downtime  table 

1NSERT_DREDG1NG_DATA  Insert  data  from  the  DSS  into  the  Dredging  Data  table 

INSERT_LOAD_DATA  Insert  summary  data  for  a  load  into  the  Load  table 

INSERT_LOAD_DISPOSAL_AREA  Insert  a  dump  event  for  a  disposal  area  Into  the  Load 

Disposal  Area  table 

INSERT_LOAD__STATION  Insert  a  dredging  event  for  a  station  (site)  into  the 

Load  Station  table 

INSERT_PROJECT_DREDGE  Insert  Information  on  a  dredge  assigned  to  a  project 

into  the  Project  Dredge  table 

INSERT_PROJECT_SUMMARY__DATA  Insert  project  summary  data  into  the  Project  Summary 

Data  table 

INSERT_STATE  Insert  information  related  to  a  change  in  the  dredge 

state  (activity)  into  the  State  table 

SELECTED ISPOSAL_AREA_DISTINCT  Retrieve  a  unique  disposal  area  name  from  the  Dis¬ 
posal  Area  Table  based  on  Its  boundary  data 

SELECT_DOWNTIME_DISTINCT  Retrieve  a  unique  downtime  event  having  a  user  speci¬ 

fied  Contract  ID,  Project  name,  Dredge  name,  and 
Start_Date_Time  from  the  Downtime  table 

SELECT_LATEST_DREDGING_DATA  Retrieve  the  data  record  from  the  Dredging  Data  table 

having  the  latest  date/time  value 

SELECT_LOAD_DISTINCT  Retrieve  the  data  from  the  Load  table  for  a  user- 

specified  Contract  ID,  Project  name,  Dredge  name, 
and  Load  Number 

SELECT_MIN_MAX_  Retrieve  the  minimum  and  maximum  date/time  values 

that  exist  in  data  records  in  the  Dredging  Data  table 
SELECT  PROCESSED_DREDGING_DATA  Retrieve  the  latest  processed  (been  assigned  a  dredge 

state  by  the  RT  Kernel  program)  data  record  in  the 
Dredging  Data  table 

SELECT_PROJECT_DISTINCT  Retrieve  a  unique  project  data  record  having  a  user- 

specified  Contract  ID,  and  Project  name  from  the  Pro¬ 
ject  table,  and  retrieve  the  District  name  from  the 
District  table 

SELECT_PROJ__SUMMARY_DISTINCT  Retiieve  a  unique  project  summary  data  record  from 

the  Project  Summary  table  having  a  user-specified 
Contract  ID,  Project  name,  and  Dredge  name 

SELECT_STATION_DISTINCT  Retrieve  a  unique  station  (dredging  area)  name  from 

the  Station  table  based  on  its  boundary  data 

SELECT_UMPROC_DREDGING_DATA  Retrieve  the  earliest  unprocessed  (not  been  assigned 

a  dredge  state  by  the  RT  Kernel  program)  data  record 
in  the  Dredging  Data  table 

UPDATE_DOWNTIME  Update  a  downtime  event  in  the  Downtime  table  with  a 

user  input  cause  and  comment 

UPDATE_DREDGING_DATA  Update  a  dredging  data  record  In  the  Dredging  Data 

table  with  a  load  number,  dredge  state,  and  TDM 
value 

UPDATE_PROJECT_SUMMARY  Update  a  project  summary  data  record  in  the  Project 

Summary  table 

Stored  procedures  are  procedures  created  specifically  for  use  by  Sybase. 

The  stored  procedures  are  created  and  changed  using  a  text  editor,  and  entered 
into  the  Sybase  DBMS  using  isql.  They  are  defined  to  Sybase  by  name  and 
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may  have  a  parameter  list,  just  like  other  procedures  in  other  languages.  They 
are  invoked  (called)  by  name  from  within  RT  Kernel  or  the  other  Ada  code 
modules  within  the  system,  and  parameters  are  then  supplied  to  match  the 
parameter  list  of  the  stored  procedure. 

The  specific  code  associated  with  each  of  these  stored  procedures  is  pro¬ 
vided  in  Appendix  A.  Each  data  element  within  the  data  tables  that  is  input, 
retrieved,  or  updated  by  these  stored  procedures  is  listed  within  this  code. 


RT  Kernel 


The  system’s  central  program  within  the  SHIP  component,  which  processes 
newly  arriving  data  and  controls  the  overall  flow  of  data,  is  called  RT  Kernel. 
RT  Kernel  starts  mnning  when  the  user  starts  the  SHIP  component  of  the 
Silent  Inspector  system  by  clicking  on  the  DOSIS  icon.  RT  Kernel  then  runs 
continuously  whether  or  not  the  DSS  is  operating  and  inserting  data  into  the 
SHIP  database.  RT  Kernel  has  several  functions; 

a.  Looks  at  each  data  record  inserted  by  the  DSS  into  the  Dredging_Data 
table  (called  unprocessed  data)  and  computes  the  dredge  state  (activity) 
occurring  at  that  time,  the  tons  dry  weight  of  material  collected  in  the 
hopper  at  that  time  (TDM),  and  assigns  a  load  number  to  the  data 
record.  Once  these  three  values  have  been  attached  to  the  data  within 
the  Dredging_Data  table,  the  data  are  considered  processed  data. 

b.  If  the  dredge  state  is  determined  to  be  “Down,”  RT  Kernel  makes  an 
entry  in  the  DOWNTIME  table. 

c.  Distributes  the  processed  data  to  other  database  tables. 

d.  Computes  and  stores  data  for  load  and  daily  reports. 

e.  Determines  when  the  end  of  a  trip  or  day  has  occurred,  and  initiates 
Unix  processes  (subroutines),  which  create  a  trip  or  daily  report. 

/.  Detennines  whether  or  not  dredging  areas  (stations)  and  disposal  areas 
related  to  the  current  project  have  been  entered  into  the  PRO- 
JECT_STATION  and  PROJECT _DlSPOSAL_ARE A  tables:  and  if  so, 
determines  whether  or  not  the  vessel  is  dredging  or  disposing  in  those 
defined  areas;  and  if  so,  enters  that  fact  into  the  LOAD_STATION  and 
LOAD_DISPOSAL_AREA  tables. 

To  perform  these  functions,  RT  Kernel  calls  upon  several  subroutines. 
Those  subroutines  in  turn  utilize  the  Sybase  stored  procedures  to  access  or 
insert  data  within  the  database  tables.  The  steps  RT  Kernel  performs  and  the 
names  of  the  subroutines  utilized  are  summarized  below  in  order  of  their 
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performance  within  RT  Kernel.  Steps  that  are  indented  represent  steps  which 
occur  within  the  called  subroutines. 

Steps  Performed  Subroutine  Names 

Log  on  to  DOSIS  datg^ase  upon  SHIP  module  startup  Database. Signon 
Initialize  ckta  monitoring  module  from  last  processed  data  lnjtialize_Data_Monitoring 

Retrieve  latest  processed  data  record  Database.Select_Processed  ^Dredg- 

ing_Data 

Retrieve  earliest  unprocessed  data  record  from  database  Get_Unprocessed_Dredging_Data;  & 

Database.  Select_Un processed  Dredg- 
ing_Data 

If  data  are  for  a  different  project,  Initialize  project  data  lnitialize_Project_Data 
Identify  disposal  areas  assigned  to  the  project  lnitialize_Disposaf_Areas 

Identify  dredging  areas  assigned  to  the  project  lnitialize_Stations 

Compute  time  between  new  and  previous  data  records  Elapsed_Time 

Compute  the  dredge  state  for  the  new  data  record  SLComputations.Compute_Dr6dge_State 

If  data  are  for  a  new  toad  (trip),  initialize  a  new  load  record  lnitiallze_Load 

Update  Load  table  for  elapsed  time  in  new  dredge  state 
Update  several  database  tables  with  new  record  data 
Check  for  ^e  end  of  a  load 
Add  load  data  to  existing  load  no.  in  Load  table 
Create  new  load  if  needed 
Check  for  a  change  in  the  dredge  state 
Add  dredge  state  change  data  to  State.  Load, 
and  Dredging_Data  tables 
Check  for  start  of  downtime  state  and 
initialize  downtime  record 
Check  for  end  of  downtime  state  and  enter  data 
Check  for  and  mark  start  of  dumping  state 
Check  for  dumping  in  a  project  disposal  area 
Add  data  to  Load_Disposal_Area  table 
Check  for  dredging  in  project  dredging  area  (station) 

Add  data  to  Load_Station  table 
If  dumping  state  is  just  completed,  and  to  cut  started, 
compute  sailing  empty  displacement 
if  not  sailing  empty,  compute  TDM 
Update  Dredging_Data  table  with  state  &  load  no. 

Complete  the  database  transaction 
Print  reports  as  necessary 
Print  a  load  (trip)  report 
Print  a  daily  report 

Save  current  processed  data  record  values  for 
use  in  processing  next  unprocessed  record 


Load_State_Time 

Kemel_Database_Tran  section 

New_State 

Add_Load 

New_Load 

New_State 

Add_State_C  hang  e 

lnitialize_Downtime 

Add_Downtime 

Dumping_Started 

Check_Di  sposal_Areas 

Add_Dumping_Entry 

Check_Stations 

Add_Dredg  ing_Entry 

SI_Computations. 

Dredge_Empty_Displacement 
SI_Computations.Tonnage_Dry_Measure 
Database .  U  pdate_Dredg  ing_Data 
Database. Commit_Transaction 
Print_Manager 
Print_Trip_Report 
Print_Daily_Report 
Save_Values 
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5  System  Computations 


The  DOSIS  system  performs  calculations  within  both  the  DSS  and  SHIP 
components.  No  computations  are  performed  within  the  SHORE  component  at 
the  present  time,  as  all  necessary  values  have  been  computed  and  stored  in  the 
DOSIS  database  prior  to  its  archiving  and  transfer  to  a  SHORE  unit. 

DSS  Component  Calculations 

Calculations  within  the  DSS  component  are  not  necessarily  identical 
between  DSS  units.  This  is  because  each  DSS  is  configured  to  receive  and 
process  a  specific  suite  of  sensor  data  being  provided  by  a  particular  dredge. 

In  all  cases,  the  output  of  the  DSS  to  the  SHIP  database  is  identical  in  its  con¬ 
tent,  format,  and  method  of  interaction  with  the  SHIP  component.  Therefore, 
while  the  DSS  calculations  may  vary,  the  calculated  values  and  their  imits  will 
remain  the  same  between  DSS  units.  The  training  and  reference  DSS  performs 
the  following  calculations: 


Calculation  Name 

Units 

Purpose 

Average  hopper  ullage 

feet 

Calculate  the  average  of  the  four  ullage 
sensor  values 

Average  hopper  level  forward 

feet 

Determine  the  level  of  the  water  in  the 
hopper  at  the  forward  end 

Average  hopper  level  aft 

feet 

Determine  the  level  of  the  water  in  the 
hopper  at  the  aft  end 

Hopper  volume 

yds^ 

Determine  the  volume  of  water  and  mate¬ 
rial  within  the  hopper  based  upon  the 
fore  and  aft  water  levels 

Port/Stbd  pump  on/off 

on/off 

Determine  if  the  port  and  starboard 
pumps  are  on  or  off 

Port/Stbd  material  recovery 

yes/no 

Determine  if  material  is  being  recovered 
through  the  port  and  starboard  drag  arms 

Status  of  parameter  values 

Ok,  Lo.  Hi,  No 

Determine  if  the  received  or  computed 
data  values  are  within  or  beyond  accept¬ 
able  limits,  as  defined  in  a  data  accept¬ 
able  range  table,  or  if  the  data  are 
missing 
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Each  of  the  DSS  calculations  are  provided  below.  The  data  parameters 
used  and  computed  in  each  calculation,  their  abbreviation  (if  any)  used  in  the 
equations,  their  units,  and  the  source  of  the  values  used  for  the  parameters  are 
presented  first.  The  source  of  a  parameter  can  either  be  a  SHIP  database  table, 
another  computation,  or  a  fixed  value  based  on  a  particular  dredge.  The  exact 
names  of  the  parameters  as  they  appear  within  the  database  tables  or  within  the 
equations  are  shown.  The  detailed  equations  are  then  listed. 


Average  hopper  ullage 

This  computation  is  a  straight  average  of  the  four  hopper  ullage  readings. 
Parameters  Used  and  Sources: 


Parameter 

Ullage  meter  No.  1 
Ullage  meter  No.  2 
Ullage  meter  No.  3 
Ullage  meter  No.  4 
Average_Ullage 

Equations: 

Average_Ullage  =  (Ullage  1 


Units 

Data  Source 

feet 

DSS 

feet 

DSS 

feet 

DSS 

feet 

DSS 

feet 

Computed 

Ullage  2  +  Ullage  3  +  Ullage  4)  /  4 


Average  hopper  level  forward 

This  computation  converts  the  forward  ullage  readings  into  an  average 
water  level  in  the  hopper  at  its  forward  end. 

Parameters  Used  and  Sources: 


Parameter 

Units 

Data  Source 

Ullage  meter  No.  1 

feet 

DSS 

Ullage  meter  No.  2 

feet 

DSS 

Average_Ullage_Fonvard 

feet 

Computed 

Hopper_Bottom_T  o_Sensors 

feet 

Fixed;  specific  to  Essayons 

Equations: 

Average_Ullage_Forward  =  (Ullage  1  +  Ullage  2)  /  2 

Average_LeveLForward  =  Hopper_Bottom_To_Sensors  -  Average_Ullage_Forward 


Note:  This  calculation  is  currently  not  performed  in  the  training  and  ref¬ 
erence  DSS.  Instead,  this  value  is  set  to  a  default  value  with  a  status  value  of 
“missing.” 
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Average  hopper  level  aft 


This  computation  converts  the  aft  ullage  readings  into  an  average  water 
level  in  the  hopper  at  its  aft  end. 

Parameters  Used  and  Sources: 


Parameter 

Units 

Data  Source 

Ullage  meter  No.  3 

feet 

DSS 

Ullage  meter  No.  4 

feet 

DSS 

Average_Ullage_Aft 

feet 

Computed 

Hopper_Bottom__T  o_Sensors 

feet 

Fixed;  specific  to  Essayons 

Equations: 

Average__Ullage__Aft  =  (Ullage  3  +  Ullage  4)  /  2 

Average_Level_Aft  =  Hopper_Bottom__To_Sensors  -  Average_Ullage_Aft 

Note:  This  calculation  is  currently  not  performed  in  the  training  arid  ref¬ 
erence  DSS.  Instead,  it  is  set  to  a  default  value  and  a  status  of  “missing.” 


Hopper  volume 

The  Essayons  hydrostatic  curves  were  used  to  derive  the  equations  used  to 
compute  the  hopper  volume.  The  average  ullage  reading  was  used  to  compute 
the  hopper  volume  as  shown  below. 

Parameters  Used  and  Sources: 


Parameter 

Units 

Data  Source 

Average_Ullage 

feet 

Computed 

Hopper__Volume 

yds^ 

Computed 

Constants 

none 

Fixed;  specific  to  Essayons 

Equations: 

If  Average_Ullage  <=11,  then 

Hopper_Volume  =  6852.57  -  (150.74067  *  Average_U!lage) 
othenwise, 

If  Average_Ullage  >11  <=31,  then 
Hopper_Volume  =  7534.1  -  (209.45  *  Average_Ullage) 

othenvise, 

If  Average_Ullage  >  31,  then 

Hopper_Volume  =  -75179.0  +  (9346.8  *  Average_Ullage)  -  (411.27  *  Aver- 
age_Ullage^)  +  (7.7651  *  Average_Ullage^)  -  (0.053733  *  Average_Ullage^) 

The  constants  listed  in  these  equations  are  derived  from  the  volume  curves/ 
equations  for  the  Essayons  hopper. 
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Port/Starboard  pumps  on/off 

Port  and  starboard  pump  on/off  determinations  are  computed  based  upon 
the  draghead  velocity  measurements. 


Parameters  Used  and  Sources: 


Parameter 

Units 

Data  Source 

Port__Draghead_Velodty 

feet/sec 

DSS 

Stbd_Drag  head_Velocity 

feet/sec 

DSS 

Pump_On_Port 

true/false 

Computed 

Pump_On_Stbd 

true/false 

Computed 

Equations: 

If  Port_Draghead_Veloclty  >  10.0,  then  Punip_On_Port  =  true  .then, 
If  Port_Draghead_Velocity  £  10.0,  then  Pump_On_Port  =  false 

otherwise 

If  Stbd_Draghead_Velocity  >  10.0,  then  Pump_On_Stbd  =  true,  then. 
If  Stbd_Draghead_Velocity  £  10.0,  then  Pump_On_Stbd  =  false 


Port/starboard  material  recovery  true/false 

Port  and  starboard  material  recovery  determinations  are  computed  based 
upon  draghead  density  measurements. 

Parameters  Used  and  Sources: 


Parameter 

PorLDraghead_Density 

Stbd_Draghead_Density 

Pump_MateriaLPort 

Pump__MateriaLStbd 


Units  Data  Source 

g/l  DSS 

g/l  DSS 

true/false  Computed 

true/false  Computed 


Equations: 

If  Port_Draghead_Density  ^  1.05,  then  Pump_Material_Port  =  true,  then, 
if  Port_Draghead_Density  <  1.05,  then  Pump_Material_Port  =  false 

otiierwise 

If  Stbd_Draghead_Density  >  1.05,  then  Pump_MaterjaLStbd  =  true,  then. 
If  Stbd_Draghead_Density  <  1 .05,  then  Pump_Material_Stbd  =  false 


Pumpout  pump  on/off 

Hopper  pumpout  pump  on/off  determinations  are  computed  based  upon 
velocity  measurements  in  the  discharge  pipe.  This  parameter  is  not  currently 
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included  in  the  parameters  supplied  Essayons  data  logging  computer  to  the 
DSS,  but  is  intended  as  a  required  parameter. 

Parameters  Used  and  Sources: 


Parameter 

Unite 

Data  Source 

Port_Discharge_Pipe_Velocity 

feet/sec 

DSS 

Stbd_Discharg0_Pipe_Velocity 

feet/sec 

DSS 

Pu  m  pout_Pump_On_Port 

true/false 

Computed 

Pu  mpout_Pu  mp_On__Stbd 

true/false 

Computed 

Equations: 

If  Port_Discharge_Pipe_Ve!ocity  >  10.0,  then  Pumpout_Pump_On_Port  =  true  .then, 
If  Port_Discharge_Pipe_Velocity  <  10.0,  then  Pumpout_Pump_On_Port  =  false 

otherwise 

If  Stbd_Discharge_Plpe_Velocity  >  10.0,  then  Pumpout_Pump_On_Stbd  =  true, 
then, 

If  Stbd_Discharge_Pipe_Velocity  £  10.0,  then  Pumpout_Pump_On_Stbd  =  false 


Data  status 

The  status  values  that  can  be  assigned  to  each  sensor  or  computed  data 
values  are: 


Status 

Abbr. 

Meaning 

ACCEPTABLE 

OK 

sensor  measurement  is  within  acceptable  limits 

OUT  OF  RANGE  LOW 

LO 

sensor  measurement  is  out-of-range  low 

OUT  OF  RANGE  HIGH 

HI 

sensor  measurement  is  out*of-range  high 

MISSING 

NO 

sensor  measurement  is  missing 

Minimum  and  maximum  acceptable  values  for  each  type  of  data  are  con¬ 
tained  within  a  file,  named  RANGE.DAT,  that  is  loaded  into  the  DSS.  The 
values  presently  set  for  use  with  the  Essayons  are  shown  in  Chapter  3.  To 
determine  the  status  of  each  data  value,  the  DSS  compares  the  values  in  each 
data  record  it  receives  to  the  minimum  and  maximum  values  in  the 
RANGE.DAT  file.  An  ADA  code  subroutine  perfomis  this  comparison. 


SHIP  Component  Calculations 

Calculations  within  all  SHIP  components  are  identical,  as  the  contents  of  all 
SHIP  databases  are  identical.  Only  when  data  values  required  for  the  calcula¬ 
tions  are  missing  or  out  of  the  acceptable  range  will  the  calculations  not  be 
performed  identically.  In  most  cases  the  necessary  calculations  can  always  be 
made;  however,  in  cases  where  a  calculation  is  not  possible,  the  value  being 
calculated  is  set  to  a  default  value,  which  is  normally  0. 

The  SHIP  component  performs  the  following  calculations: 
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Calculation  Name 


Load  number 


Tons  dry  measure 


Dredge  state 


Dredging  area 


Disposal  area 


Time  summations 


Units 

integer 

long  tons 

none 

none 

none 

hh:mm:ss 


Purpose 

Calculates  and  assigns  a  consecutive  load  num¬ 
ber  to  each  load  performed  on  a  dredging  project, 
as  defined  by  the  project  name  and  contract  ID. 

Calculates  the  weight  of  sediment  in  the  hopper 
on  a  dry  weight  basis  assuming  an  individual 
sediment  particle  density  of  2,650  g/cm^. 

Calculates  the  activity  the  dredge  is  performing  at 
the  time  of  each  measurement  record  (10-sec 
intervals). 

Calculates  and  assigns  the  name  of  a  dredging 
location  to  each  load  by  comparing  the  dredge’s 
position  during  dredging  of  the  load  with  pre¬ 
entered  dredging  area  coordinates. 

Calculates  and  assigns  the  name  of  a  disposal 
area  to  each  load  by  comparing  the  dredge’s 
position  during  dumping  of  the  load  with  pre¬ 
entered  disposal  area  coordinates. 

Calculates  the  amount  of  time  the  dredge  per¬ 
forms  various  activities  dunng  a  load,  a  day.  and 
a  job,  or  other  time  period  defined  by  the  user. 


Details  of  each  of  the  SHIP  calculations  are  provided  below.  Again,  where 
practical,  a  graphical  overview  of  the  data  parameters  used  and  computed  from 
each  calculation  is  presented  first.  The  exact  names  of  the  parameters  as  they 
appear  within  the  database  tables  or  within  the  equations  are  shown.  The 
detailed  equations  are  then  listed,  followed  by  a  table  which  lists  each  param¬ 
eter,  its  abbreviation  (if  any)  used  in  the  equations,  its  units,  and  the  source  of 
the  values  used  for  the  parameters. 


Load  number 

A  new  load  number  is  computed  after  each  dumping  phase  has  been  com¬ 
pleted.  Load  numbers  are  computed  by  incrementing  the  previous  load  num¬ 
ber  by  1.  The  load  number  is  the  highest  load  number  currently  in  the 
DREDGING _D AT  A  table  for  the  current  contract  ID  and  dredge  name.  If  no 
data  exist  in  the  DREDGING_DATA  table  for  the  contract  ID  and  dredge 
name,  then  the  initial  load  number  is  set  to  1. 


Tons  dry  measure 

The  TDM  value  is  computed  in  two  steps,  as  follows: 

a.  Determine  the  displacement  of  the  dredge  when  the  hopper  is  empty. 

b.  Determine  the  tonnage  dry  measure  of  the  material  in  the  hopper. 
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The  detailed  computations  within  each  of  these  steps  proceed  as  follows; 
Step  1:  Determine  the  displacement  of  the  dredge  when  empty. 
Parameters  Used  and  Source: 


Abbr. 

Parameter 

Units 

Data  Source 

HV 

Hopper_Volume 

yd^ 

Dredging__Data  table 

We 

Empty_Displacemont 

long  tons 

Computed 

W, 

T  otaLDIsplacement 

long  tons 

Computed 

Deb 

Center_Bu  oyancy_Draft 

feet 

Computed 

Df 

Vessel_Draft_Forward 

feet 

Dredging_Data  table 

Da 

Vessel_Draft_Aft 

feet 

Dredging_Data  table 

Bf 

Buoyancy_Fonward  (60.417) 

feet 

Specific  to  Essayons 

Ba 

Buoyancy__Aft  (1 21 .91 7) 

feet 

Specific  to  Essayons 

SC 

Slope^Closed  (591.667) 

none 

Specific  to  Essayons 

CC 

constant  ebsed  (-2383.333) 

none 

Specific  to  Essayons 

mdL  Water_Density  (1025.0) 

g/i 

Fixed 

Cf 

Conversjon_Factor  (1328.8) 

none 

Fixed 

Values  for  constants  are  shown  in  parentheses  after  the  parameter  name. 
Constants  specific  to  the  Essayons  were  obtained  from  the  vessel’s  specifica¬ 
tions.  The  factor  for  converting  long  tons  per  cubic  yard  into  grams  per  liter 
is  1328.8. 

Equations: 


If  HV  <=  0.0,  then 
Wq  =  8300.0 

else  (otherwise): 

D,b  =  D,+  (D3-D,)*(B,/B3) 

W,  =  sc  *  D(,b  +  CC 
Wg  =  W,  -  (HV  *  md^  /  C,) 

Step  2:  Determine  the  tonnage  dry  measurement  of  material  within  the 
hopper. 

Parameters  Used  and  Source: 


Abbr.  Parameter 

HV  Hopper_Volume 
Wq  Empty_Displacement 
TotaLDis  placement 
Dpij  Center_Buoyancy_Draft 
Df  VesseLDraft_Forward 
VesseLDraft_Aft 
Buoyancy_Fonvard  (60.41 7) 
Bg  Buoyancy_Aft  (121 .91 7) 

SC  Slope_Closed  (591 .667) 

CC  Constant  closed  (-2383.333) 
md^  Water__Density  (1025.0) 
mdj^  Load_Denslty 
md^  Dfy_Material_Denslty  (2650.0) 
C|  Conversion_Factor  (1328.8) 
TDM  Tonnage_Dry_Measure 


Units 

Data  Source 

yd^ 

Dredging_Data  table 

long  tons 

Computed 

long  tons 

Computed 

feet 

Computed 

feet 

Dredging_Data  table 

feet 

Dredging_Data  table 

feet 

Specific  to  Essayons 

feet 

Specific  to  Essayons 

none 

Specific  to  Essayons 

none 

Specific  to  Essayons 

Fixed 

g/» 

Computed 

Fixed 

none 

Fixed 

long  tons 

Computed 
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Equations: 


if  HV  <=  0.0,  then 
TDM  =  0.0 

otherwise; 

Dcb  =  D,+  (Da-D,)‘{B,/B,) 

W,  =.  SC  *  D^b  +  CC 

mdh  =  ((W,  -  Wg)  /  HV)  *  1328.8 

TDM  =  ((mdf,  -  md^„)  /  (md^  •  mdj)  *  md^  *  HV  /  C, 

The  constant  values  listed  above  are  for  the  Essayons,  and  are  directly 
coded  into  the  TDM  equations  utilized  within  RT  Kernel.  The  Setup  module 
will  eventually  permit  the  user  to  enter  these  values  into  the  Dredge  table.  RT 
Kernel  will  then  look  these  constant  values  up  within  the  dredge  table  accord¬ 
ing  to  the  dredge  in  use. 


Dredge  state 

For  each  data  record  arriving  from  the  DSS,  the  system  calculates  the  ongo¬ 
ing  activity  at  the  time  of  the  measurements.  These  activities  are  called  dredge 
states.  The  system  currently  assigns  one  of  seven  dredging  states  to  each  data 
record.  The  dredge  states  are: 

a.  Sailing  empty. 

b.  Dredging  material. 

c.  Pumping  (with  no  material  recovery). 

d.  Turning. 

e.  Sailing  fuU. 

/.  Dumping. 

g.  Downtime. 

Calculating  the  dredge  state  is  perfonned  in  eight  steps.  These  steps  are  as 
follows: 

a.  Compute  the  rate  of  change  of  the  vessel  heading. 

b.  Determine  the  maximum  draft  for  detecting  turning. 

c.  Compute  the  depth  above  which  the  dragheads  will  be  considered  up 
(minimum  dredging  depth),  and  no  dredging  is  occurring. 

d.  Check  if  either  pump  is  pumping  material. 
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e.  Check  if  both  dragheads  are  raised  above  the  minimum  dredging  depth. 

/.  Determine  whether  or  not  the  vessel  is  turning. 

g.  Determine  which  dredge  states  are  possible. 

h.  Determine  which  dredge  state  is  occurring  based  on  the  computed  pos¬ 
sible  dredge  states  (results  of  item  g). 

Steps  a-f  compute  information  needed  to  determine  which  dredge  states 
may  exist  (Step  g).  The  final  selection  of  a  dredge  state  from  the  possible 
dredge  states  is  performed  in  Step  h.  The  detailed  computations  within  each 
of  the  eight  steps  are  shown  below. 

In  these  computations,  certain  values  in  the  equations,  such  as  the  Mini- 
mum_Sailing_Speed,  are  fixed  within  the  system.  These  values  were  entered 
during  system  development  and  cannot  be  changed  except  by  a  systems  engi¬ 
neer.  The  forward/aft  empty  and  loaded  drafts  are  for  the  Essayons\  the 
remaining  values  are  appropriate  for  use  on  any  dredge.  These  parameters, 
and  their  current  values,  are  listed  below: 


Parameter 

Value 

Units 

Forward_Draft_Loaded 

24.0 

feet 

Forward_Draft_Empty 

17.0 

feet 

Aft_Draft_Loaded 

26.0 

feet 

Aft_Draft_Empty 

24.5 

feet 

Minimum_Turning_Rate 

.05 

degrees 

Minima  m_Sailing_Speed 

4.0 

knots 

Minima  m_Dredging_Speed 

0.1 

knots 

Minimam_Damping_Speed 

0,1 

knots 

Step  a:  Determine  a  rate  of  change  of  the  gyro  heading. 

Parameters  Used  and  Sources: 

Parameter 

Units 

Data  Source 

Vessel_Heading 

degrees 

Dredging_Data  table 

Previoas_Course 

degrees 

Dredging_Data  table 

Gyro_Rate 

degrees/sec 

Computed 

Equations: 

If  Delta_Time  >  0.0,  then 

=  [(Vessel_Heading  - 

Previous  Course)  /  Delta_Time)] 

Step  b:  Determine  the  maximum  vessel  draft  of  fore  and  aft  readings. 

Parameters  Used  and  Sources: 

Parameter 

Units 

Data  Source 

VesseLDraft_Forward 

feet 

Dredging_Data  table 

VessGl_Draft_Aft 

feet 

Dredging_Data  table 
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Maximum_Draft 


feet 


Computed 


Equations: 

If  Vessel_Draft_Forward  >  VesseLDraft_Aft,  then 
Maximum^Draft  =  Dredging_Draft_Forward, 

otherwise: 

Maximum_Draft  =  Dredging_Draft_Aft 


Step  c:  Determine  the  minimum  dredging  depth. 
Parameters  Used  and  Sources: 


Parameter 

Units 

Data  Source 

Ve  s  sel_Draft_Forward 

feet 

Dredging_Data  table 

Water_Depth 

feet 

Dredging_Data  table 

Mlnimum_Dredging_Depth 

feet 

Computed 

Equations: 

Minim um__Dredg in g_Depth  =  0.75  *  (Vessel__Draft_Forward  +  Water_Depth) 

Step  d:  Determine  if  material  is  being  recovered. 

Parameters  Used  and  Sources: 


Parameter 

Units 

Data  Source 

Pump_On_Port 

Yes/No 

Dredging_Data  table 

Pump_On_Stbd 

Yes/No 

Dredging_Data  table 

Pump_Material_Port 

Yes/No 

Dredging_Data  table 

Pum  p_Mate  rial_Stbd 

Yes/No 

Dredging_Data  table 

PumpIng^Material 

Yes/No 

Computed 

Equations: 

Pumping_Material  is  true  if: 

Pump_On_Port  =  True,  and 
Pump_Material_Port  =  True,  or  if 
Pump_On_Stbd  =  True,  and 
Pump_Materia!_Stbd  =  True 

Step  e:  Determine  if  both  dragheads  are  up. 
Parameters  Used  and  Sources: 


Parameter 


Units 


Data  Source 


Port_Draghead_Depth  Status 
Stbd_Draghead_Depth  Status 
Water_Depth  Status 
Draghead_Depth_Port 
Draghead_Depth_Stbd 
Maximum_Draft 


Ok,  Lo.  Hi.  No 

Ok,  Lo,  Hi,  No 

Ok,  Lo.  Hi.  No 

feet 

feet 

feet 


Dredging_Status  table 
Dredging_Status  table 
Dredging_Status  table 
Dredging_Data  table 
Dredging_Data  table 
Computed 
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Minjmum_Dredging_Depth  feet  Fixed 

Dragheads^Up  Yes/No  Computed 

Equations: 

Dragheads_Up  is  true  if: 

Port_Draghead_Deplh  Status  =  Acceptable,  and 
Draghead_Depth_Port  <=  Maxim um_Draft,  and 
Stbd_Draghead_Depth  Status  =  Acceptable,  and 
Draghead_Depth_Stbd  <=  Maxim um_Draft, 

otherwise: 

Water_Depth  Status  -  Acceptable,  and 
Port_Draghead_Depth  Status  =  Acceptable,  and 
Draghead_Depth_Port  <=  Mlnimum_Dredging_Depth,  and 
Stbd_Draghead_Depth  Status  =  Acceptable,  and 
Draghead_Depth_Stbd  <=  Minimum_Dredging_Depth 


Step/:  Determine  if  vessel  is  turning. 

Parameters  Used  and  Sources: 


Parameter 

Units 

Data  Source 

Gyro^Rate 

degrees 

Computed 

Minimum_Turning_Rate 

degrees 

Fixed 

Tuming_Vessel 

Yes/No 

Computed 

Equations: 

Turning^Vessel  is  true  if: 

OyroJRate  >  Minim um_Tuming_Rate 


Step  g:  Determine  the  possible  dredge  state(s). 

Determination  of  possible  dredge  states  is  summarized  in  the  Dredge  Status 
Computation  Logic  Table  (Table  2).  Each  dredge  state  has  a  unique  set  of 
conditions.  If  the  computations  cannot  determine  a  unique  dredge  state,  the 
system  attaches  a  “Downtime”  dredge  state  designation  to  the  data  record. 

Parameters  Used  and  Sources: 


Parameter 

Units 

Data  Source 

Pumping_Material 

true/false 

Computed 

Pump_On_Port 

true/false 

Dredging_Data  table 

Pump_On_Stbd 

true/false 

Dredging_Data  table 

Ground_Speed_Statu  s 

Ok,  Lo.  Hi,  No 

Dredging_Status  table 

VesseLSpeed 

knots 

Dredging_Data  table 

Minimum_Dredging_Speed  (0.1) 

knots 

Fixed 

Course__Status 

Ok,  Lo,  Hi,  No 

Dredging_Status  table 

Gyro_Rate 

degrees 

Computed 

Minimum_Tuming_Rate  (.05) 

degrees/sec 

Fixed 

Port_Draghead_Depth_Status 

Ok,  Lo,  Hi,  No 

Dredging_Status  table 

Stbd_Draghead_Depth_Status 

Ok,  Lo,  Hi,  No 

Dredging_Status  table 

Draghead_Depth_Port 

feet 

Dredging_Data  table 

Draghead_Depth_Stbd 

feet 

Dredging_Data  table 
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Maximum_Draft 

feet 

Computed 

Minimum_Sailing_Speed  (4.0) 

knots 

Fixed 

Minimum_Dumping_Speed  (0. 1 ) 

knots 

Fixed 

Dragheads_Up 

true/false 

Computed 

Hopper_Door_Open 

true/false 

Dredging_Data  table 

State 

none 

Computed 

Tuming_Ves$el 

true/false 

Computed 

Forward_Draft__Statu  s 

Ok,  Lo,  Hi.  No 

Dredging_Status  table 

Aft_DrafLStatus 

Ok,  Lo.  Hi.  No 

Dredging_Status  table 

VesseLDraft_Forward 

feet 

Dredging^Data  table 

VesseLDraft_Aft 

feet 

Dredging_Data  table 

Fonvard_Draft_Loaded  (24.0) 

feet 

Fixed;  specific  to  Essayons 

AfLDraft_Loaded  (26.0) 

feet 

Fixed;  specific  to  Essayons 

Fonward_Draft_Empty  (17.0) 

feet 

Fixed;  specific  to  Essayons 

Aft_Draft_Empty  (24.5) 

feet 

Fixed;  specific  to  Essayons 

Equations: 


Dredging_MateriaLState  is  true  if: 

Pumplng_Material  (results  of  Step  4)  is  True,  and 
Hopper_Door_Open  is  False 

Pumping_State  (no  material  recovery)  is  true  if: 
Pumping_Materiai  (results  of  Step  4)  is  False,  and 
Pump_On_Port  is  True,  or 
Pump_On_Stbd  is  True 

Pump_On_Stbd  is  False,  and 
Ground_Speed_Status  =  Acceptable,  or 
Vessel_Speed  >  Minimum_Dredging_Speed,  and 
Course_Status  =  Acceptable,  or 
Gyro_Rate  <  Minimum_Turning_Rate 

Turning_State  is  true  if: 

Port_Draghead_Depth  Status  =  Acceptable,  and 
Draghead_Depth_Port  <=  Maximum_Draft,  and 
Stbd_Draghead_Depth  Status  =  Acceptable,  and 
Draghead_Depth_Stbd  <=  Maximum_Draft,  and 
Ground_Speed_Status  =  Acceptable,  or 
Vessel_Speed  <  Mlnimuni_Sailing_Speed,  and 
Punip_Material_Port  is  False,  and 
Pump_Materlal_Stbd  is  False,  and 
Dragheads_Up,  and 
Pumping_Materiai  is  False,  and 
Hopper_Door_Open  is  False,  and 
Course_Status  =  Acceptable,  or 
Gyro_Rate  >=  Minimum_Turning_Rate,  and 
State  =  Pumping,  Turning,  or  Down 

Dumping_State  is  true  if: 

Hopper_Door_Open  is  True,  and 
Ground_Speed_Status  =  Acceptable,  or 
Vessel_Speed  >  Minimum_Dumplng_Speed.  and 
Vessel_Speed  <  Minimum_Sailing_Speed,  and 
State  =  To-Dump,  Dumping,  or  Down 

Sailing_Full_State  is  true  if: 

Pump_On_Port  is  False,  and 

Pump_On_Stbd  is  False,  and 

Pumping_Material  is  False,  and 

Turning_Vessel  is  False,  and 

Dragheads_Up  is  True,  and 

Forward__Draft  Status  =  Acceptable,  and 

VesseLDraft_Forward  >  Forward_Draft_Loaded,  and 
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Aft_Draft_Status  =  Acceptable,  and 
VesseLDraft_Aft  >  Aft_Draft_Loaded,  and 
Ground_Speed_Status  =  Acceptable,  or 
Vessel_Speed  >=  Minimum_Sailing_Speed,  and 
State  =  Pumping,  Turning,  To_Dump,  or  Down 

Sailing_Empty_State  is  true  if: 

Pump_On_Port  is  False,  and 
Pump_On__Stbd  is  False,  and 
Pumping_Material  is  False,  and 
Turning_Vessel  is  False,  and 
Dragheads_Up  is  True,  and 
Forward_DrafLStatus  =  Acceptable,  and 
VesseLDraft_Forward  <  Forward_Draft_Empty,  and 
Aft_Draft_Status  =  Acceptable,  and 
Vessel_Draft_Aft  <  Aft_Draft_Empty,  and 
Ground_Speed_Status  =  Acceptable,  or 
Vessel_Speed  >=  Minimum_SaiIing_Speed,  and 
State  =  Dumping,  To_Cut,  or  Down 

Step  h:  Determine,  rename,  dredge  state  from  possible  states. 

The  selection  of  the  actual  dredge  state  to  be  assigned  to  a  data  record  from 
the  possible  dredge  state(s)  computed  under  step  g  is  performed  using  the 
following  priority:  dumping,  pumping  (material  or  water),  to-cut,  to-dump, 
turning,  down.  If  dumping  is  computed  within  step  g  as  a  possible  dredge 
state,  then  dumping  is  selected  as  the  dredge  state  as  it  is  given  the  highest 
selection  priority.  If  dumping  is  not  a  possible  dredge  state,  then  the  next 
dredge  state  in  the  priority  list  which  is  also  included  in  the  possible  dredge 
states  is  assigned  to  the  data  record. 


Dredging  area  (station) 

A  dredging  area  can  be  made  up  of  1  to  10  rectangular  areas.  For  each 
dredging  record  where  the  dredge  state  is  PUMPING,  a  test  is  made  to  deter¬ 
mine  if  the  current  vessel  position  is  within  one  of  these  rectangular  areas.  If 
so,  a  record  is  added  to  the  LOAD-STATION  table  indicating  that  the  dredge 
was  dredging  in  that  area  during  the  current  load.  If  the  dredge  is  not  pump¬ 
ing  in  an  assigned  dredging  area,  that  too  is  recorded  in  the  LOAD_STATION 
table. 


Disposai  area 

A  disposal  area  can  be  made  up  of  1  to  10  rectangular  areas.  For  each 
dredging  record  where  the  dredge  state  is  dumping,  a  test  is  made  to  determine 
if  the  current  vessel  position  is  within  one  of  these  rectangular  areas.  If  so,  a 
record  is  added  to  the  LOAD_DISPOSAL_AREA  table  indicating  that  the 
dredge  was  dumping  in  that  dredging  area  during  the  current  load.  If  the 
dredge  is  not  dumping  in  an  assigned  dredging  area,  that  too  is  recorded  in  the 
LOAD_DISPOSAL_AREA  table. 
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Time  summations  for  reports 


Trip,  daily,  and  job-to-date  reports  contain  summations  of  the  time  certain 
activities  have  occurred,  such  as  the  amount  of  time  each  dredge  state  has 
occurred  within  the  reporting  time  period.  These  time  summations  are  per¬ 
formed  by  the  subroutines,  initiated  by  RT  Kernel,  which  generate  the  reports. 
The  time  summations  are  a  straight  summation  based  on  the  times  attached  to 
each  data  record  in  the  DREDGING_DATA  table  for  a  trip  (load),  day,  or  job- 
to-date. 
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6  System  Interfaces 


The  Silent  Inspector  system  contains  four  main  interfaces  between  the  sys¬ 
tems  components,  and  between  the  system  and  other  types  of  hardware  plat¬ 
forms  and  software.  These  interfaces  and  their  purpose  are: 


Interface  Purpose 


Sensors  to  DSS 
DSS  to  SHIP 
SHIP  to  SHORE 
Outside  Access 


Transfer  of  sensor  data  to  the  DSS  component 
Transfer  of  data  from  DSS  to  SHIP  database 
Transfer  of  data  from  SHIP  to  SHORE  components 
Access  to  the  SHIP  or  SHORE  databases  using  other  types 
of  software 


Overviews  of  each  interface,  and  its  specifications  and  format  requirements, 
are  provided  below. 


Sensors-to-DSS  Interface 

As  each  hopper  dredge  has  a  different  suite  of  electronic  sensors,  the  inter¬ 
face  between  the  sensors,  or  a  sensor  data  collection  computer,  and  the  DSS 
component  will  vary  from  dredge  to  dredge.  It  is  anticipated  that  no  two 
sensor-to-DSS  interfaces  may  be  exactly  alike.  What  is  important  is  that  each 
DSS  must  take  these  varied  inputs  and  create  a  standard,  identical  format  data 
record  for  insertion  into  the  SHIP  database. 

When  the  data  are  received  by  the  DSS  via  RS232,  the  data  should  have 
already  been  converted  into  engineering  units  and  data  calibrations  applied,  so 
the  data  are  considered  final,  true  values.  If  other  than  RS232  data  inputs  are 
to  be  received,  such  as  sensor  voltages,  the  conversions  of  the  sensor  outputs 
to  useable  units  and  calibrated  values  may  be  programmed  into  the  DSS. 

The  training  and  reference  DSS  was  designed  specifically  for  the  Coips  of 
Engineers  hopper  dredge  Essayons,  which  already  has  a  data  logging  computer 
aboard.  The  DSS  was  therefore  designed  to  accept  sensor  data  in  RS232  for¬ 
mat.  So  as  to  allow  development  and  testing  of  the  DSS  and  SHIP  compo¬ 
nents,  the  DSS  also  accepts  sensor  data  from  pre-recorded  data  files  of 
Essayons  data.  The  sensor-to-DSS  interface  fonnat  was  structured  to  match 
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the  format  output  by  the  Essay  on’s  data  logging  computer.  Each  data  record  is 
127  characters  followed  by  a  carriage  return  line-feed  <cilf>.  The  specific 
sensor  data  in  each  incoming  record,  and  its  format,  character  length,  and  posi¬ 
tion  within  each  127-character  record,  are  shown  below. 


Sensor  Data 
(Parameter) 

Units 

Flag 

none 

Date 

yymmdd  (local) 

Time 

seconds  (local) 

RMS  Error 

feet 

X  location 

feet 

Y  location 

feet 

Forward  draft 

feet 

Aft  draft 

feet 

Tide  elevation 

feet 

Port  drag  arm  velocity 

feet/sec 

Port  drag  arm  density 

grams/liter 

Starboard  drag  arm  velocity 

feet/sec 

Starboard  drag  arm  density 

grams/liter 

Port  gimbal  depth 

feet 

Starboard  gimbal  depth 

feet 

Port  draghead  depth 

feet 

Starboard  draghead  depth 

feet 

Heading 

degrees  true 

Course 

degrees  true 

Water  depth  (below  hull) 

feet 

Speed  (over  ground) 

knots 

Ship  weight-hopper  open 

long  tons 

Ship  weight-hopper  closed 

long  tons 

Ullage  -  meter  no.  1 

feet 

Ullage  -  meter  no.  2 

feet 

Ullage  -  meter  no.  3 

feet 

Ullage  -  meter  no.  4 

feet 

Hopper  door  open 

true/false 

Data 

Character 

Character 

Format 

Length 

Position 

ASCII  string 

6 

1  -6 

ASCII  string 

6 

7-12 

Floating  point 

5 

13-17 

Floating  point 

4 

18-21 

Floating  point 

7 

22-28 

Floating  point 

7 

29-35 

Floating  point 

6 

36-41 

Floating  point 

6 

42-47 

Floating  point 

5 

48-52 

Floating  point 

4 

53-56 

Floating  point 

4 

57-60 

Floating  point 

4 

61-64 

Floating  point 

4 

65-68 

Floating  point 

4 

69-72 

Floating  point 

4 

73-76 

Floating  point 

4 

77-80 

Floating  point 

4 

81-84 

Floating  point 

3 

85-87 

Floating  point 

3 

88-90 

Floating  point 

4 

91-94 

Floating  point 

4 

95-98 

Floating  point 

6 

99-104 

Floating  point 

6 

105-110 

Floating  point 

4 

111-114 

Floating  point 

4 

115-118 

Floating  point 

4 

119-122 

Floating  point 

4 

123-126 

ASCII  string 

1 

127 

Definitions  of  the  data  to  be  provided  for  each  parameter  are  shown  below. 
Specific  value  ranges  or  limitations  specific  to  the  Essayons  data  record  are 
also  listed.  Note  that  for  all  parameters  having  a  floating  point  data  format, 
the  position  of  the  decimal  place  varies  and  is  contained  within  the  characters 
sent  for  each  parameter. 


Sensor  Data 
(Parameter) 

Date 

Time 

Root  mean  square 
(RMS)  Error 

X  location 
Y  location 


Definition 


Date  in  local  time  of  the  sensor  measurements,  formatted  yymmdd. 

Seconds  past  midnight,  from  0.000  to  86400,  local  time. 

RMS  error  of  ship’s  position  based  on  the  X  and  Y  range  values  used 
to  calculate  the  position.  Valid  numbers  range  from  0.00  to  32.9, 
which  is  the  maximum  value  tolerated  in  the  Essayon's  positioning 
system. 

X  (easting)  Lambert  position  of  the  dredge. 

Y  (northing)  Lambert  position  of  the  dredge. 
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Forward  and  aft  draft 

Tide  elevation 

Port  &  Stbd  drag  arm  velocity 
Port  &  Stbd  drag  arm  density 

Port  &  Stbd  gimbal  depth 
Port  &  Stbd  draghead  depth 

Heading 

Course 

Water  depth 

Speed 
Ship  weight 
Ullage 


Hopper  doors  open 


Draft  of  vessel  below  waterline  at  the  forward  and  aft  sensor 
locations.  On  the  Essayons,  forward  draft  range  =  1 0  to 
30  ft,  aft  draft  range  =  20  to  30  ft. 

Tide  height  relative  to  mean  lower  low  water. 

Velocity  of  water  moving  through  the  drag  arms. 

Specific  gravity  of  water/material  mixture  in  the  drag  arms. 
Valid  values  are  1 .0  to  2.0;  values  <  1 .0  indicate  no  water  in 
the  drag  arm. 

Depth  below  water  surface  of  the  drag  arm  gimbals.  Valid 
range  for  Essayons  is  0.00  to  50.0. 

Depth  below  water  surface  of  the  low  fixed  point  of  each 
draghead.  This  value  includes  a  correction  for  the  draft  and 
trim  of  the  vessei,  and  is  not  depth  below  the  keel. 

Heading  in  degrees  of  the  vessel  as  taken  from  the  Gyro¬ 
compass.  Values  are  from  0.00  to  359. 

Vessel  course  in  degrees  made  good  as  computed  from  the 
vessel’s  navigation  system  data  over  10-sec  intervais. 

Depth  below  the  keel  at  the  location  of  the  sensor.  This 
sensor  is  not  in  piace  on  the  Essayons,  and  therefore  no 
data  are  provided  for  this  parameter. 

Vessel  speed  over  the  ground  as  computed  from  the  ves¬ 
sel’s  navigation  system  data  over  10-sec  intervals. 

Weight  of  the  vessel  with  the  doors  open  and  closed.  Not 
currently  included  in  the  data  record. 

Height  of  water  in  the  hopper.  This  is  computed  as  the 
distance  between  the  water  surface  to  the  Ullage  sensor, 
subtracted  from  the  distance  between  the  bottom  of  the 
hopper  to  the  Ullage  sensor.  The  Essayons  has  four  Ullage 
sensors  located  in  each  corner  of  the  hopper.  A  value  for 
each  sensor  Is  included  in  the  data  record. 

Status  of  the  hopper  doors  as  either  open  (true),  all  doors 
all  the  way  closed  (false),  or  undetermined  (unknown).  Any 
single  hopper  door  open  requires  a  door  open  status. 


The  training  and  reference  DSS  accepts  data  records  as  fast  as  the  Essayons 
data  logging  computer  sends  such  records.  At  present,  data  records  are  sent  by 
the  Essayons  computer  and  received  by  the  DSS  every  10  sec.  The  required 
spacing  for  the  receipt  of  sensor  data  by  all  DSS  components  is  to  be  no  more 
than  10-sec  intervals. 


DSS-to-SHIP  Interface 

After  receiving  input  of  a  sensor  data  record,  the  DSS  attaches  three  opera¬ 
tor  input  and  several  DSS  computed  parameters  to  the  data  record  and  stores 
the  complete  outgoing  record  in  a  database  format  suitable  for  transfer  to  the 
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SHIP  database.  The  additional  parameters  attached  to  each  data  record,  and 
their  source,  are: 


Parameter 

Units 

Data  Format 

Source 

Contract  ID 

None 

ASCII  string 

Operator  Input  to  DSS 

Project  name 

None 

ASCII  string 

Operator  input  to  DSS 

Dredge  name 

None 

ASCII  string 

Operator  input  to  DSS 

Date_Tlme 

local 

Sybase  datetime 

Converted  by  DSS  into 
Sybase  datetime  format  from 
the  date  and  time  inputs 

Average  hopper  level  forward 

feet 

Floating  point 

Computed  by  DSS 

Average  hopper  level  aft 

feet 

Floating  point 

Computed  by  DSS 

Average  hopper  level 

feet 

Floating  point 

Computed  by  DSS 

Hopper  volume 

yards^ 

Floating  point 

Computed  by  DSS 

Port  pump  on 

true/false 

ASCII  string 

Computed  by  DSS 

Starboard  pump  on 

true/false 

ASCII  string 

Computed  by  DSS 

Port  material  recovery 

true/false 

ASCII  string 

Computed  by  DSS 

Starboard  material  recovery 

true/false 

ASCII  string 

Computed  by  DSS 

Pump  out  on 

true/false 

ASCII  string 

Computed  by  DSS 

Status  value  for  each  parameter 

ok,  lo,  hi,  no 

ASCII  string 

Computed  by  DSS 

The  definitions  of  the  data  for  the  parameters  input  by  the  operator  or  com¬ 
puted  by  the  DSS  are  shown  below.  See  Chapter  5  for  details  of  specific 
computations. 

Parameter  DeKnition 

Contract  ID  The  unique  contract  number  or  identifier  under  which  the  dredging 

data  were  collected. 

Project  name  The  name  of  the  project  under  which  the  dredging  data  were 

collected. 

Dredge  name  The  name  of  the  dredge  on  which  the  dredging  data  were  collected. 

Date_Time  The  date  and  time,  in  a  Sybase  Datetime  format,  at  which  the  mea¬ 

surements  in  this  record  were  taken.  Sybase  accepts  the  date  and 
time  in  several  different  formats  (e.g.,  940930,  10:45:50.4AM).  Refer 
to  the  Sybase  Manuals  for  the  acceptable  formats. 

Avg.  hopper  level  forward  Average  height  of  water  or  material  in  the  fonvard  end  of  the  hopper 
as  computed  from  the  two  forward  ullage  sensors. 

Avg.  hopper  level  aft  Average  height  of  water  or  material  in  the  aft  end  of  the  hopper  as 

computed  from  the  two  aft  ullage  sensors. 

Avg.  hopper  level  Average  height  of  water  or  material  in  the  hopper  as  computed  from 

the  computed  fonward  and  aft  average  hopper  levels. 

Hopper  volume  The  volume  of  water  and  material  In  the  hopper  as  computed  from  the 

computed  average  hopper  level  and  equations  describing  the  hopper 
volume  versus  height  in  the  hopper. 

Port  pump  on  The  port  dredging  pump  is  on  (true),  off  (false),  or  undetermined 

(unknown)  as  computed  from  the  Port  Drag  Arm  Velocity  value. 

Starboard  pump  on  The  starboard  dredging  pump  is  on  (true),  off  (false),  or  undetermined 

(unknown)  as  computed  from  the  Starboard  Drag  Arm  Velocity  value. 
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Port  material  Tecovery 


The  port  dredging  pump  is  pumping  material  (true),  not  pumping 
materid  (false),  or  undetermined  if  it  is  pumping  material  (unknown) 
as  computed  from  the  Port  Drag  Arm  Density  value. 

Starboard  material  recovery  The  starboard  dredging  pump  is  pumping  material  (frue),  not  pumping 
material  (false),  or  undetermined  If  it  is  pumping  material  (unknown) 
as  computed  from  the  Starboard  Drag  Arm  Density  value. 

Pump-out  on  The  pump-out  pump  (for  discharge  of  the  hopper  contents  through  a 

pipeline)  is  on  (true),  off  (false),  or  undetermined  (unknown)  as 
computed  from  the  Pump-CXJt  Pump  Velocity  value.  Note  that  ttiis 
value  is  not  provided  in  frie  Essayons  127-character  data  record  input 
into  the  DSS. 

Status  of  parameter  values  A  data  quality  flag  assigned  to  all  parameters  having  numerical  val¬ 
ues.  The  validity  of  each  parameter  value  is  determined  by  compar¬ 
ing  the  value  agaunst  a  table  of  acceptable  ranges  (see  Chapter  3), 
and  given  the  following  data  quality  flags: 


OK 

- 

measurement  is  acceptable 

LO 

- 

measurement  is  out-of-range  low 

HI 

- 

measurement  is  out-of-range  high 

NO 

- 

measurement  is  missing 

While  each  DSS  will  have  different  interface  specifications  between  the 
sensors  and  the  DSS,  as  well  as  different  methods  of  handling  the  sensor  data 
within  the  DSS  to  some  extent,  aU  DSS  components  must  create  identical 
completed  data  records  stored  within  the  DSS  data  structure  and  transfer  these 
completed  records  into  the  SHIP  database  in  identical  fashion.  All  DSS-to- 
SHIP  interfaces  must  therefore  meet  the  following  specifications. 

Once  the  DSS  has  accepted  a  data  record  from  the  sensors,  attached  the 
three  operator  input  parameter  values,  and  computed  the  values  for  the  addi¬ 
tional  parameters  listed  above,  it  stores  the  new  completed  record  in  a  data 
structure  within  the  DSS.  Once  in  this  data  structure,  the  data  record  is  now 
ready  for  transfer  to  the  SHIP  central  database.  If  the  SHIP  component  is  not 
on-line,  the  DSS  presently  cannot  transfer  these  data  into  the  SHIP  central 
database.  These  data  can  be  written  directly  to  a  data  file,  as  is  the  case  with 
the  training  and  reference  DSS,  and  played  back  at  a  later  time  to  insert  into 
the  SHIP  central  database.  The  data  record  within  the  DSS  data  structure  is 
over-written  as  each  new  sensor  record  is  obtained  and  completed  by  the  DSS. 

After  a  completed  record  has  been  inserted  into  the  DSS  database  structure 
and  the  SHIP  component  is  on-line,  the  DSS  will  insert  the  newly  completed 
record  into  the  DREDGING_DATA  table  within  the  SHIP  component’s  central 
database.  The  DSS  must  do  this  by  communicating  directly  with  the  SHIP 
database  on  a  client-server  basis.  Communications  between  the  DSS  and  SHIP 
database  are  performed  in  structured  query  language  (SQL)  format  using 
Sybase  Library  calls  and  stored  procedures.  The  SQL  operation  used  to  store 
the  contents  of  the  DSS  database  structure  into  the  DREDGING_DATA  table 
is  the  Insert  operation.  The  Insert  operation  is  presently  invoked  by  calling 
the  database  interface  package,  written  in  ADA  code,  named  Database.  The 
Sybase  Insert  operation  for  the  DREDGING _D AT  A  table  is  provided  in  that 
package.  The  Insert  operation  contained  within  the  Sybase  Open/ADA  inter¬ 
face  may  also  be  used  rather  than  the  Database  package.  If  the  DSS  code  is 
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written  in  C,  the  insert  operation  in  the  Sybase  Open/C  interface  should  be 
used.  The  stored  procedure  named  JNSERT_DREDG1NG_DATA  may  also  be 
invoked  directly  from  any  language.  The  DSS  does  not  interact  with  any  other 
tables  within  the  SHIP  database,  or  with  any  other  portion  of  the  SHIP 
component. 

Listed  below  are  the  parameters  contained  within  the  DSS  data  structure, 
the  corresponding  field  name  for  the  parameter  in  the  DREDGINGjDATA 
table,  and  the  length,  in  bytes,  of  the  field.  The  definition,  units,  and  data  for¬ 
mat  for  each  parameter  remain  the  same  as  listed  in  tables  above.  All  status 
parameters  specify  the  validity  of  corresponding  measurements  (see  Chapter  3). 
Note  that  values  for  ten  parameters  input  into  the  DSS  in  the  original 
127 -character  sensor  data  record  are  not  contained  within  the  DSS  data  struc¬ 
ture,  nor  inserted  into  the  DREDGING_DATA  table.  These  parameters  are: 
port  drag  arm  velocity,  starboard  drag  arm  velocity,  port  drag  arm  density, 
starboard  drag  arm  density,  port  drag  arm  gimbal  depth,  starboard  drag  arm 
gimbal  depth,  and  ullage  meter  numbers  1-4. 


Parameter  Name 

DREDGING_DArA 

Field 

Field  Name 

Length 

Contract  ID  (number) 

CONTRACT  ID 

32 

Project  name 

PROJECT 

32 

Dredge  name 

DREDGE 

32 

Date  &  time 

DATE  TIME 

8 

X  location 

VESSEL  X 

8 

X  location  data  status 

VESSEL  X  STATUS 

2 

Y  location 

VESSEL  Y 

8 

Y  location  data  status 

VESSEL  Y  STATUS 

2 

Fonward  draft 

VESSEL  DRAFT  FORWARD 

8 

Forward  draft  data  status 

VESSEL  DRAFT  FORWARD  STATUS 

2 

Aft  draft 

VESSEL  DRAFT  AFT 

8 

Aft  draft  data  status 

VESSEL  DRAFT  AFT  STATUS 

2 

Speed  (over  ground) 

VESSEL  SPEED 

8 

Speed  data  status 

VESSEL  SPEED  STATUS 

2 

Heading 

VESSEL  HEADING 

8 

Heading  data  status 

VESSEL  HEADING  STATUS 

2 

Course 

VESSEL  COURSE 

8 

Course  data  status 

VESSEL  COURSE  STATUS 

2 

Port  draghead  depth 

DRAGHEAD  DEPTH  PORT 

8 

Port  draghead  depth  data  status 

DRAGHEAD  DEPTH  PORT  STATUS 

2 

Stbd  draghead  depth 

DRAGHEAD  DEPTH  STBD 

8 

Stbd  draghead  depth  data  status 

DRAGHEAD  DEPTH  STBD  STATUS 

2 

Avg.  hopper  level  forward 

HOPPER^LEVEL^FORWARD 

8 

Avg.  hopper  level  fnwd  data  status 

HOPPER  LEVEL  FORWARD  STATUS 

2 

Avg.  hopper  level  aft 

HOPPER  LEVEL  AFT 

8 

Avg.  hopper  level  aft  data  status 

HOPPER  LEVEL  AFT  STATUS 

2 

Avg.  hopper  level 

HOPPER  ULLAGE 

8 

Avg.  hopper  level  data  status 

HOPPER  ULLAGE  STATUS 

2 

Hopper  volume 

HOPPER  VOLUME 

8 

Hopper  volume  data  status 

HOPPER  VOLUME  STATUS 

2 

Water  depth 

WATER^DEPTH 

8 

Water  depth  data  status 

WATER  DEPTH  STATUS 

2 

Tide  elevation 

TIDE 

8 

Tide  elevation  data  status 

TIDE  STATUS 

2 

Hopper  door  status 

HOPPER  DOOR  OPEN 

7 

Port  pump  on 

PUMP  ON  PORT 

7 

Starboard  pump  on 

PUMP  ON  STBD 

7 

Port  material  recovery 

PUMP  MATERIAL  PORT 

7 
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Starboard  material  recovery 
Pump-out  on 


7 

7 


PUMP_MATERIAL_STBD 
PUMP_OUT_ON 

Each  data  record  transmitted  from  the  DSS  to  SHIP  must  represent  sensor 
data  collected  at  a  maximum  interval  of  10  sec  apart.  In  the  case  of  the  train¬ 
ing  and  reference  DSS,  recorded  data  files  may  also  be  transmitted  to  the  SHIP 
database.  In  this  case,  the  user  may  redefine  the  time  associated  with  each 
data  record  after  the  first  data  record  by  setting  a  time  interval  to  be  added  to 
the  first  record’s  time  value,  as  described  earlier  in  Chapter  3.  The  DSS  then 
transmits  all  the  recorded  data  records  within  a  file  at  the  maximum  possible 
computer  communications  speed.  This  allows  for  faster  playback  and  testing 
of  (he  system  than  is  possible  otherwise.  This  feature  may  not  necessarily  be 
provided  on  any  production  DSS  component. 


SHIP-to-SHORE  Interface 

Currently  the  SHIP-to-SHORE  interface  is  performed  using  the  Archive 
module.  This  module  copies  the  data  from  six  SHIP  database  tables  into  Unix 
archive  files,  which  are  then  transferred  to  a  storage  medium  (tape)  at  the 
user’s  direction.  These  files  may  then  be  loaded  into  any  DOSIS  database 
residing  within  a  SHIP  or  SHORE  component.  The  format  for  these  archive 
files  is  described  in  the  “Archive  Files  and  Procedures’’  section  of  this  manual. 


Outside  Access  Interface 

No  specific  interface  has  been  developed  to  allow  other  software  and  hard¬ 
ware  platforms  to  interact  directly  with  the  Silent  Inspector  components  and 
software.  There  is,  however,  an  interface  built  directly  into  the  Sybase  Data¬ 
base  program  that  allows  other  software  to  access  the  DOSIS  database  on  the 
SHIP  or  SHORE  component,  provided  that  the  proper  user  ID  and  password 
are  provided. 

The  Sybase  database  contains  the  Open  Database  Connectivity  (ODBC) 
driver.  External  software  programs  containing  this  driver  can  be  linked  and 
data  from  the  DOSIS  database  can  be  either  inserted  or  copied.  Insertion  of 
data  is  permitted  only  into  selected  database  tables  where  user  input  is 
required.  Data  may  be  copied  from  aU  tables.  Tables  containing  measured  or 
computed  values  are  read  only,  and  cannot  be  altered  by  external  software 
programs. 
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7  SHIP  Software  Modules 


The  SHIP  component  contains  the  database  server  executing  the  relational 
DBMS.  SHIP  also  executes  user-initiated  application  software  that  operates  as 
clients  of  the  DBMS,  accessing  information  in  the  database  to  perform  data¬ 
base  maintenance,  real-time  data  monitoring,  reporting,  and  graphical  data  dis¬ 
plays.  The  SHIP  applications  software  contains  several  major  subsystems,  or 
modules.  Each  user-invoked  module  is  either  a  stand-alone  operational  com¬ 
ponent,  or  is  composed  of  multiple  operational  components.  Each  module  is 
user  initiated  through  graphical  user  interface  screens  and  icons.  The  user- 
invoked  modules  presently  contained  within  the  SHIP  system  and  their  func¬ 
tion  are: 

Module  Function 

Setup  User  entry  of  project  and  dredge  Information. 

Monitoring  User  viewing  of  incoming  data. 

Downtime  User  entry  of  downtime  causes  and  comments  (Identification  of  downtime 

events  is  performed  automatically  within  RT  Kernel,  which  is  not  user- 
invoked). 

Reports  User-initiated  display  and  printing  of  pre-defined  reports. 

Plotting  User  viewing  of  data  within  the  database. 

Backup  Automatic  backup  of  selected  database  tables  and  data;  user-initiated  restora¬ 

tion  of  the  database  from  the  backup  files. 

Archive  Combination  automatic  and  user-initiated  archiving  of  selected  database 

tables  and  data  for  transfer  to  SHORE  component  and  permanent  record 
keeping. 

These  modules  and  their  components  are  described  briefly  below. 

Setup 

Information  related  to  a  dredging  project,  including  the  dredge  name  and 
characteristics,  crew,  designated  dredging  and  disposal  areas,  and  landmarks 
related  to  the  local  marine  waters  can  be  entered  into  the  system  by  the  user. 
This  information  is  entered  into  the  system  through  the  system’s  Setup  module. 
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The  information  is  entered  by  the  user  into  one  of  six  SHIP  database  tables. 
The  table  names  and  the  information  which  can  be  entered  into  each  are  listed 
below.  Characteristics  of  each  data  element  within  these  tables  are  more  com¬ 
pletely  described  in  Table  1.  Inforaiation  the  user  can  enter  into  each  table  is 
listed  below. 

CREWMEMBER  Table: 

First  name 
Last  name 
Rank 

ID  (Initials) 

DISPOSAL^AREA  Table: 

Disposal  area  name 

Four  X,  y  coordinates  forming  a  rectangle  to  represent  the  disposal  area 

DISTRICT  Table: 

Corps  of  Engineers  District  names 
Abbreviations  for  the  District  names 

DREDGE  Table: 

Dredge  name 
Dredge  owner  name 
Dredge  type 
Year  built 
Vessel  beam 
Vessel  length 

Vessel  dredge  pumps  horsepower 

Vessel  displacement:  empty  and  full 

Vessel  maximum  speed:  empty  and  full 

Vessel  draft:  fore  and  aft  when  empty  and  loaded 

Distance  to  draft  sensors  along  vessel  hull 

Hopper  maximum  capacity 

Distance  in  hopper  to  ullage  sensors 

LANDMARK  Table: 

Landmark  name 

X,  y  coordinates  of  landmark  location 

PROJECT  Table: 

Project  name 
Contract  number  (ID) 

Contractor  name 
Corps  of  Engineers  District  name 
Project  type:  new  work  or  maintenance 
Anticipated  start/finish  dates 

STATION  (Dredging  areas)  Table: 

Dredging  area  name 

X,  y  coordinates  forming  rectangle  to  represent  the  dredging  area 


The  SETUP  module  is  activated  by  clicking  on  the  SETUP  icon,  and  then 
clicking  on  the  icon  for  the  type  of  data  the  user  wishes  to  enter.  Optionally, 
the  user  may  use  a  pull-down  menu  to  access  the  components  within  the 
SET-UP  module.  In  either  case,  the  user  is  supplied  with  a  screen  listing  entry 
boxes  for  all  tlie  information  which  may  be  entered  or  changed  related  to  the 
database  table  selected  (type  of  information  being  input).  It  is  intended  that 
infomiation  may  be  entered  via  the  SETUP  module  either  directly  on  a  SHIP 
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system  computer  or  into  a  portable  laptop  computer.  Information  can  be 
entered  into  the  SHIP  database  tables  via  connectivity  options  provided  by  the 
ODBC  capabilities  of  the  Sybase  DBMS. 


Monitoring 


The  DATA  MONITORING  module  provides  a  real-time  display  of  the 
data  being  stored  by  the  DSS  in  the  SHIP  database.  It  accomplishes  this  by 
performing  the  following  five  major  functions: 

a.  Displays  the  most  current  set  of  data  values  stored  by  the  DSS  in  the 
DREDGING_DATA  table. 

b.  Computes  and  displays  the  load  number  associated  with  the  displayed 
data  values. 

c.  Computes  and  displays  the  current  TDM  value  associated  with  the 
displayed  data  values. 

d.  Plots  the  computed  TDM  values  over  a  short  time  period  to  allow  the 
user  to  see  the  trend  of  the  vessel’s  loading. 

e.  Computes  and  displays  the  current  dredge  state  associated  with  the 
displayed  data  values. 


The  application  which  accomplishes  the  above  actions  is  written  in  Ada 
code  and  is  started  by  clicking  on  the  DATA  MONITORING  icon  on  the 
SHIP  main  menu  screen. 


Downtime 

The  DOWNTIME  module  permits  the  user  to  display  information  about 
the  dredge  downtime  periods  which  have  been  identified  and  recorded  as  such 
in  the  database  by  the  system,  and  to  annotate  any  downtime  period  with  a 
cause  and  a  comment,  both  of  which  are  then  stored  with  the  downtime  record 
within  the  database.  The  operator  may  select  to  view  all  downtime  events 
recorded  in  the  database,  or  only  those  for  which  no  cause  or  comment  has 
already  been  entered.  Information  entered  by  the  user  is  entered  into  the 
DOWNTIME  table  within  the  database.  The  application  to  accomplish  the 
user  access  and  selection  of  a  downtime  event,  and  entry  of  a  cause  and  com¬ 
ment,  is  written  in  ADA  code,  and  is  started  by  clicking  on  the  DOWNTIME 
icon  on  the  SHIP  main  menu  screen. 
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Reports 


The  REPORT  module  provides  the  user  the  ability  to  display  and  print  the 
following  pre-defined  reports:  trip  report,  daily  report,  and  job  report.  Each 
report  is  displayed  and  printed  by  a  separate  software  component  addressed 
through  the  overall  REPORT  module  written  in  Ada  code.  The  reports  con¬ 
tain  the  following: 

Trip  Report  Lists  the  start  time  and  associated  data  values  for  all 
dredge  state  changes  that  occur  during  a  trip  (load). 
The  report  contains  one  entry  for  each  dredge  state 
change. 


Daily  Report  Lists  data  values  for  each  trip  started  during  a  day, 

along  with  summations  of  relevant  values  and  duration 
of  each  dredge  state  over  the  trips  listed  in  the  report. 

Job  Report  Lists  summations  of  relevant  values  and  duration  of 

each  dredge  state  from  the  beginning  of  a  project  to  the 
date  of  the  report.  This  component  also  urates  the 
database  table  PROJECT  SUMMARY  with  this  infor¬ 
mation  at  the  user’s  option. 


The  REPORT  module  allows  the  user,  by  clicking  on  the  appropriate  icon, 
to  review  a  list  of  the  trip  or  daily  reports  contained  within  the  database  for 
any  project  identified  by  any  contract  ID  and  dredge  name.  The  user  may 
select  the  report  of  interest  from  the  displayed  list  by  clicking  on  the  trip  num¬ 
ber  or  day  of  interest.  The  report  will  then  be  displayed  and  optionally 
printed.  The  user  cannot  change  or  edit  the  report. 


The  job  report  is  always  regenerated  from  the  data  within  the  database 
whenever  the  user  invokes  this  component  of  the  REPORT  module.  The 
newly  generated  job  totals  will  first  be  displayed  and,  at  the  option  of  the  user, 
printed  and/or  entered  as  updated  information  within  the  database. 


Plotting 

The  PLOTTING  module  permits  the  user  to  interactively  select  data  within 
the  database  and  generate  time  series  plots  of  the  selected  data.  This  module 
uses  general  purpose  plotting  software  developed  specifically  for  the  Silent 
Inspector  system.  The  PLOTTING  module’s  overall  controlling  software  is  in 
ADA  code.  This  code  is  activated  by  clicking  on  the  PLOTTING  icon  on  the 
SHIP  main  menu  screen. 

Currently  the  user  can  select  up  to  four  data  elements  to  be  plotted  at  the 
same  time  on  the  Y  axis  versus  time  on  the  X  axis.  The  values  for  the  data 
elements  selected  can  be  obtained  from  the  database  by  selecting  a  trip 
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number,  in  which  case  all  values  for  the  trip  (for  the  data  elements  selected) 
will  be  plotted,  or  by  time  interval,  in  which  case  only  those  values  within  the 
specified  time  interval  will  be  plotted.  All  data  elements  to  be  plotted  together 
must  have  the  same  units  so  that  they  may  be  plotted  on  the  same  plot.  Time 
along  the  X  axis  is  plotted  at  a  specified  scale;  therefore,  if  the  data  being 
plotted  span  a  longer  time  than  can  be  displayed  on  the  screen,  a  horizontal 
slider  bar  is  provided  to  allow  the  user  to  scroll  through  the  data. 


Backup  and  Archive 

Backup  and  archive  are  two  separate  modules  which  operate  in  a  similar 
manner.  The  function  of  the  backup  module  is  to  automatically  copy  database 
data  to  backup  files  which  would  enable  the  SHIP  database  to  resume  operat¬ 
ing  after  a  catastrophic  loss.  While  creation  of  the  backup  files  is  automatic, 
restoring  the  SHIP  database  using  the  backup  files  must  be  user  initiated. 

The  function  of  the  archive  module  is  to  remove  old  data  from  the  SHIP 
database  for  transmission  to  SHORE  components  and  permanent  record  keep¬ 
ing.  The  archive  module  automatically  transfers  data  to  Unix  files,  then  the 
user  must  initiate  transfer  of  the  Unix  files  to  another  medium  (disk,  tape,  etc.) 
for  transfer,  storage,  and  loading  into  a  SHORE  component. 

The  backup  and  archive  modules  copy  data  contained  in  six  user  tables 
within  the  SHIP  database  to  external  files.  These  six  tables  are: 

•  DOWNTIME 

•  DREDGING_DATA 

•  LOAD 

•  LOAD_DISPOSAL_AREA 

•  LOAD_STATION 

•  STATE 

The  backup  and  archiving  modules  are  currently  not  accessible  and  cannot 
be  initiated  from  the  graphical  user  interface  screens  specific  to  the  Silent 
Inspector  system.  These  modules  are  different  from  most  of  the  other  user- 
invoked  modules  in  that  they  are  not  controlled  by  ADA  code,  but  instead  are 
currently  launched  using  Unix  shell  scripts  entered  on  the  main  Unix  user 
interface  screen.  All  scripts  are  written  using  Unix  c  shell  (csh)  code. 

Because  these  Unix  scripts  are  not  launched  by  clicking  on  icons  to  activate 
ADA  code,  they  are  described  and  listed  below,  as  the  user  must  enter  them  to 
activate  certain  parts  of  the  backup  and  archive  processes. 
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Unix  environment  variabies 


Certain  Unix  environment  variables  must  be  set  to  permit  the  backup/ 
recovery  and  the  archive/restore  facilities  to  woric  correctly.  They  may  be  set 
for  an  individual  user  by  adding  their  definitions  to  the  user’s  .login  file  for 
the  c  shell  or  the  .profile  file  for  the  Bourne  shell  in  (he  user’s  home  directory. 
They  may  be  set  for  all  users  by  adding  their  definitions  to  the  cshrc  file  for 
the  c  shell  or  the  profile  file  for  the  Bourne  shell  in  the  /etc  directory.  The 
syntax  for  setting  an  environment  variable  is  shown  below  for  both  shells. 

c  shell  setenv  variable-name  value 

Example:  setenv  D0S1S_ARCHIVE  /usr/dosis/archive 

Bourne  shell  variable-name=value 

export  variable-name 

Example:  DOSIS_ARCHIVE=/usr/dosis/archive 
export  D0SIS_ARCH1VE 

The  following  list  contains  the  environment  variables  that  must  be  defined 
for  the  backup/recovery  and  archive/restore  facilities.  Note  that  the  variable 
names  are  in  upper  case.  A  brief  description  is  included  for  each  variable. 


Variable 


Description 


DOSIS  ARCHIVE 


DOSIS_BACKUP 


DOSIS_COMMAND_DIR 


DOSIS_DUMP_DEVICE 


DOSIS  TAPE 


SA  PASSWORD 


The  full  path  name  of  the  directory  used  by  the  archive  and 
restore  facility  to  store  files.  During  an  archive  operation,  tfie 
files  written  from  the  database  are  stored  in  this  directory  prior 
to  being  written  to  tape.  During  a  restore  operation,  the  files 
read  from  tape  are  stored  in  this  directory  prior  to  being 
loaded  into  tfie  database. 

The  full  path  name  of  the  directory  used  by  Ihe  backup  and 
recovery  facility  to  store  files.  The  database  dump  file  and  the 
transaction  log  files  are  stored  in  this  directory. 

The  full  path  name  of  the  directory  that  contains  the  command 
files  (e.g.,  dosis_restore,  dosis__clean,  etc.)  used  by  the  opera¬ 
tor  to  Initiate  recovery,  archive  and  restore  operations. 

The  device  name  of  the  Sybase  dump  device  on  which  the 
database  backup  and  transaction  log  files  are  written.  Refer 
to  the  description  of  the  sp_addumpdevice  command  in  the 
Sybase  Manuals. 

Default  tape  device  (e.g.,  /dev/rmtO  for  QIC  tape  device)  on 
which  archive  files  are  written  during  an  archive  operation  or 
read  during  a  restore  operation. 

The  Sybase  password  to  be  used  when  the  recovery,  archive, 
and  restore  commands  signon  to  isql. 


Although  aU  variables  do  not  have  functionality  in  all  scripts,  all  variables 
must  be  set  when  running  any  script.  This  is  because  a  common  script, 
check_vars,  is  called  from  all  the  other  scripts  to  verify  that  environment 
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variables  have  been  set.  Any  script  that  automatically  runs  one  of  the  DOSIS 
backup  and  archive  scripts  will  have  to  set  these  environment  variables 
appropriately. 

The  check_vars  script  is  caUed  from  all  the  other  backup  or  archive  scripts 
to  verify  that  aU  required  environment  variables  have  been  set.  Specifically,  it 
performs  the  following  checks: 

a.  SA_PASSWORD  environment  variable  is  set,  and  is,  in  fact,  the 
Sybase  password  for  the  user  “sa.” 

b.  DOSIS_ARCHIVE  environment  variable  is  set  and  designates  a 
directory. 

c.  D0SIS_BACKUP  environment  variable  is  set  and  designates  a 
directory. 

d.  D0S1S_C0MMAND_D1R  environment  variable  is  set  and  designates  a 
directory. 

e.  DOSIS_DUMP_DEVICE  envirorunent  variable  is  set  and  designates  a 
dump  device  on  the  Sybase  SQL  server. 

The  check_vars  script  also  sets  several  shell  programming  variables  for  the 
convenience  of  other  scripts. 


Backup  files  and  procedures 

There  are  two  types  of  backup  files:  database  backup  and  transaction  log 
backup  files.  The  file  created  by  a  database  backup  includes  the  entire  con¬ 
tents  of  the  six  SHIP  database  tables  listed  earlier  in  this  section,  whereas  the 
file  created  by  a  transaction  log  backup  includes  only  data  added  to  those 
tables  since  the  last  transaction  log  backup.  The  backup  module  performs  a 
database  backup  once  a  week,  and  a  transaction  log  backup  once  a  day, 
although  these  frequencies  may  be  adjusted  by  a  systems  engineer.  One  previ¬ 
ous  cycle  of  database  and  transaction  log  backup  files  are  maintained,  and 
older  backup  files  are  automatically  deleted.  Database  backup  files  are  named: 
yyyymmddX.dbd,  where  yyyymmdd  represents  the  computer’s  numeric  encod¬ 
ing  for  the  date  the  backup  was  performed  and  X  is  a  character  suffix  (a  to  z) 
used  to  sequence  database  backups  made  on  the  same  day.  Transaction  log 
backup  files  are  named:  yyyymmddX.tlb,  where  the  variables  are  the  same  as 
for  the  database  backup  name. 

If  a  SHIP  database  loss  occurred,  the  user  must  initiate  restoration  of  the 
SHIP  database  using  the  backup  files.  This  will  not  occur  automatically.  The 
Unix  script  to  perform  this  action  is  entered  into  a  Unix  window  accessed  by 
clicking  on  the  Unix  main  screen,  and  then  clicking  on  K-Shell  within  the 
Unix  menu.  The  Unix  backup  scripts  and  their  purpose  are: 
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Unix  Script 


Purpose 


dosis_dumpdb  Dumps  the  entire  contents  of  the  six  SHIP  database  tables  to  Unix 
backup  files  once  per  week. 

dosis_dumptran  Dumps  the  data  acquired  within  the  six  SHIP  database  tables  since 
the  last  transaction  log  dump  to  Unix  backup  files  once  per  day. 


dosis_restore  Restores  the  contents  of  the  six  SHIP  database  tables  using  the  data¬ 
base  backup  and  transaction  log  Unix  backup  files. 


The  Unix  scripts  dosis_dumpdb  and  dosis_dumptran  are  automatically  acti¬ 
vated,  while  the  dosis_restore  script  must  be  user  entered.  The  specific  actions 
which  occur  with  each  script  are  listed  below. 


dosisjiumpdb  Script 

The  dosis_dumpdb  script  perfonns  a  Sybase  database  dump  of  the  DOSIS 
database  to  begin  a  new  backup  cycle.  In  addition,  it  automatically  deletes  all 
old  database  and  transaction  log  dumps,  except  for  the  most  recent.  The  fol¬ 
lowing  specific  operations  are  performed: 

a.  Remove  the  files  for  all  old  database  dumps,  except  for  the  most  recent. 

b.  Remove  aU  transaction  log  dumps  corresponding  to  each  database  dump 
removed. 

c.  Determine  the  correct  name  for  the  new  database  dump.  (Dump  files 
are  named  with  the  date,  as  yyyymmdd,  followed  by  an  alphabetic 
suffix  (a,  b,  c,  etc.)  to  sequentially  indicate  dumps  on  that  date.  Provi¬ 
sion  is  made  for  several  backup  dumps  occurring  on  the  same  day, 
since  various  archive  operations  can  cause  data  backup  dumps  to  occur. 

d.  Ensure  that  t!»  ’select  into’  option  (set  for  various  archive  operations, 
as  noted  herein)  is  turned  off  for  the  DOSIS  database. 

e.  Truncate  the  transaction  log  in  the  DOSIS  database. 

/.  Dump  the  DOSIS  database  and  rename  the  dump  file  as  required  by  the 
DOSIS  backup  naming  conventions.  The  dump  command  used  on  the 
Sybase  SQL  server  causes  the  dump  to  always  be  sent  to  the  same  file; 
the  file  must  be  renamed  to  save  it  in  accordance  with  the  DOSIS 
dump  naming  conventions. 

Dosis_dumpdb  is  automated  to  run  once  a  week;  however,  this  frequency 
can  be  altered  if  desired.  As  noted  elsewhere,  database  dumps  are  also  taken 
as  part  of  various  archive  operations,  and  the  operator  can  also  explicitly  initi¬ 
ate  a  database  dump  at  any  time. 
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dosisjiumptran  Script 

The  dosis_dumptran  script  performs  a  Sybase  transaction  log  dump  of  the 
DOSIS  database  to  save  the  latest  incremental  dump  within  a  backup  cycle. 
The  following  specific  operations  are  performed. 

1.  Determine  the  correct  name  for  the  new  transaction  log  dump.  (Dump 
files  are  named  with  the  date,  as  yyyymmdd,  followed  by  an  alphabetic 
suffix  (a,  b,  c,  etc.)  to  sequentially  indicate  dumps  on  that  date.  Provi¬ 
sion  is  made  for  several  backup  dumps  occurring  on  the  same  day, 
since  various  archive  operations  cause  backup  dumps  to  be  recorded. 

2.  Dump  the  DOSIS  transaction  log  and  rename  the  dump  file  as  required 
by  the  DOSIS  backup  naming  conventions.  The  dump  command  used 
on  the  Sybase  SQL  server  causes  the  dump  to  always  be  sent  to  the 
same  file;  the  file  must  be  renamed  to  save  it  in  accordance  with  the 
DOSIS  dump  naming  conventions. 

It  is  planned  that  dosis_dumptran  wiU  be  automated  to  run  once  a  day; 
however,  this  frequency  can  be  altered  if  desired.  As  noted  elsewhere,  trans¬ 
action  log  dumps  are  also  taken  as  part  of  various  archive  operations,  and  the 
operator  can  explicitly  initiate  a  database  dump. 


dosis_restore  Script 

The  dosis_restore  script  loads  the  latest  database  dump,  followed  by  subse¬ 
quent  transaction  log  dumps,  to  restore  the  DOSIS  database  after  it  has  been 
lost  due  to  some  catastrophic  circumstance.  The  dosis_restore  script  will  be 
run  only  upon  explicit  operator  request.  The  following  specific  actions  are 
performed: 

a.  Determine  the  name  of  the  latest  database  dump  (or  give  an  error  if  no 
database  dumps  are  available.) 

b.  Load  the  latest  database  dump. 

c.  Load,  in  sequence,  all  transaction  log  dumps  taken  subsequent  to  that 
database  dump. 

Once  the  data  recovery  process  has  been  completed,  the  Silent  Inspector 
system  must  be  restarted  by  re-entering  a  user  ID  and  password. 


Archive  files  and  procedures 

Data  from  the  six  database  tables  listed  earlier  are  automatically  archived  to 
Unix  files  once  a  month.  This  frequency  may  be  changed  by  a  systems  engi¬ 
neer.  Users  may  also  initiate  the  archiving  process.  The  archiving  process 
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also  deletes  the  data  from  the  six  SHIP  database  files  after  it  has  copied  this 
data  to  the  Unix  files.  The  Unix  archive  files  are  named  yyyymmddXXX.ad, 
where  yyyymmdd  designates  the  date  of  archiving,  and  XXX  designates  the 
database  table  name.  The  XXX  abbreviations  for  the  table  names  are; 


SHIP  Database  Table  Name  XXX  Abbreviation 


DOWNTIME  DWN 

DREDGING^DATA  DDA 

LOAD^DISPOSAL^AREA  LDA 

LOAD_STATION  LST 

LOAD^TABLE  LDT 

STATE  STA 


Once  the  Unix  archive  files  have  been  created,  the  user  must  initiate  the 
transfer  or  copying  of  the  files  to  other  medium,  such  as  disk  or  tape,  deleting 
the  Unix  files  fiom  the  hard  drive,  and  loading  the  files  into  a  separate  SHIP 
or  SHORE  unit  Unix  script  to  perform  these  actions,  as  well  as  initiate  the 
archive  process,  are  entered  into  a  Unix  window  accessed  by  clicking  on  the 
Unix  main  screen,  and  then  clicking  on  K-SheU  within  the  Unix  menu.  The 
Unix  scripts  and  their  purposes  are: 


Unix  Script 

dosis_archive 

dosis_tape 

dosis_cl©an 

dosisjoad 


Purpose 

Forces  an  archive  of  the  six  database  tables  to  Unix  fifes,  and  deletes 
these  data  from  the  SHIP  database  tables. 

Copies  the  Unix  archive  files  for  a  given  date  to  a  tape. 

Deletes  Unix  archive  files  selected  by  the  user  from  the  system  hard 
drive. 

Loads  archived  files  into  a  SHIP  or  SHORE  database. 


The  following  specific  actions  occur  for  each  script. 


dosisjarchive  Script 

The  dosis_archive  script  writes  data  for  all  completed  loads  to  six  archive 
files  (corresponding  to  the  six  SHIP  database  tables),  then  deletes  all  data 
within  the  SHIP  tables  which  were  archived.  The  following  specific  operations 
are  performed. 

1.  Verify  that  an  archive  has  not  already  been  performed  on  the  current 
day  (Archive  files  are  named  to  include  the  date  and  should  not  be 
overwritten  since  archived  data  are  deleted  from  the  database.) 

2.  Dump  the  Sybase  transaction  log.  This  is  done  to  enable  recovery  to 
the  time  of  the  archive  if  something  goes  wrong  with  the  deletion  of 
data  during  the  archive  process. 
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3.  Enable  “select  into”  in  the  DOSIS  database.  This  is  done  to  allow  the 
archived  data  to  be  subset  from  the  database  via  “select  into”  (the  most 
expedient  method). 

4.  Bulk  copy  data  for  the  six  dynamic  tables  to  the  archive  fdes.  Various 
checks  are  made  to  ensure  that  all  data  that  are  supposed  to  be  archived 
have  been  successfully  bulk  copied. 

5.  Delete  data  that  had  been  archived  from  the  six  dynamic  tables.  The 
deletions  are  done  after  the  archive  is  complete,  so  that  no  data  will  be 
deleted  if  any  archive  operation  fails. 

6.  Dump  the  DOSIS  database  (via  script  dosis_dumpdb,  which  also  resets 
the  “select  into”  option).  This  is  done  because  the  ’select  into’  opera¬ 
tion  disables  future  transaction  log  dumps,  so  it  is  necessary  to  dump 
the  entire  database  to  begin  a  new  backup  cycle. 


dosisjape  Script 

The  dosis_tape  script  copies  Unix  archive  files  (created  by  the 
dosis_archive  script)  for  a  given  date  to  a  tape  device  and  will  run  only  upon 
explicit  operator  request  The  archive  files  are  not  deleted  after  the  tape  is 
created  in  case  it  is  desired  to  make  several  tapes  of  the  same  archive.  The 
dosis_clean  script  is  provided  to  remove  all  archive  files  for  a  given  date.  The 
following  specific  actions  are  performed: 

a.  Decide  whether  a  date  has  been  specified  as  an  argument  If  no  date  is 
specified,  then  the  date  of  the  oldest  archive  is  used.  If  the  command 
line  contains  two  arguments,  the  first  is  the  date  (in  yyyymmdd  format), 
and  the  second  is  the  tape  device  to  use.  If  the  command  line  contains 
only  one  argument,  the  single  argument  could  be  either  the  date  or  the 
tape  device;  dosis_tape  assumes  that  it  is  a  date  if  it  begins  with  19  or 
20;  otherwise,  the  single  argument  is  taken  to  be  a  device  name.  If  the 
command  line  contains  no  arguments,  then  neither  the  date  nor  the  tape 
device  has  been  explicitly  specified. 

b.  Decide  whether  or  not  a  tape  device  has  been  specified  as  an  argument. 
If  no  tape  device  is  specified,  the  value  of  the  environment  variable 
DOSISJTAPE  is  used  for  the  name  of  the  tape  device. 

c.  Verify  that  the  tape  device  specified  is  a  valid  device. 

d.  Verify  that  all  archive  files  are  present  for  the  date  to  be  used. 

e.  Create  a  saved  data  set  on  the  target  tape  device  containing  the  archive 
files  from  the  appropriate  date  for  the  six  dynamic  tables. 
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dosis_clean  Script 

The  dosis_clean  script  deletes  all  archive  files  for  a  specified  date  or  for 
the  oldest  date  stored,  if  no  date  is  specified  as  a  parameter.  This  feature  only 
runs  by  explicit  operator  action.  The  following  specific  operations  are 
performed. 

a.  Determine  whether  or  not  a  date  has  been  given  as  a  parameter. 

b.  Use  the  date  specified  or  the  oldest  date  on  an  archive  file  to  delete  all 
archive  files  for  that  date. 


dosisjoad  Script 

The  dosisjoad  script  loads  a  set  of  archived  data  into  a  DOSIS  database. 

The  dosisjoad  script  will  typically  be  mn  only  at  shore  sites  to  load  archived 
data  received  from  various  dredges.  The  following  specific  actions  are 
performed. 

a.  Determine  the  name  of  the  tape  drive  from  which  the  archived  data  are 
to  be  loaded.  The  tape  drive  may  be  specified  by  command  line  argu¬ 
ment  or  by  the  value  of  the  environment  variable  D0S1S_TAPE. 

b.  Verify  that  the  tape  drive  specified  is  a  valid  device. 

c.  Copy  the  files  from  the  tape  to  the  $DOSIS_ARCHIVE  directory. 

d.  Verify  that  the  correct  number  of  files  have  been  read  from  the  tape. 

e.  Determine  the  date  of  the  archive  from  the  names  of  the  files  and 
verify  that  all  files  came  from  the  same  date. 

/.  Verify  that  files  corresponding  to  all  dynamic  tables  saved  in  the 

archive  have  been  read  from  the  tape.  (There  is  one  file  for  each  table, 
since  the  file  is  created  by  bulk  copy.  The  name  of  the  table  is 
encoded  in  the  name  of  the  file.) 

g.  Dump  the  Sybase  transaction  log.  This  is  done  to  enable  recovery  to 
the  time  of  the  load  if  a  partial  load  causes  inconsistent  data  to  be 
entered  into  the  database. 

h.  Enable  “select  into”  in  the  DOSIS  database.  This  is  done  to  allow  the 
archived  data  to  be  loaded  via  bulk  copy  (the  most  expedient  method) 
and  to  allow  simple  script  creation  of  a  table  used  to  verify  that  dupli¬ 
cate  data  are  not  being  loaded. 

/.  Verify  that  data  being  loaded  do  not  duplicate  data  already  present  in 
the  database.  This  is  done  by  copying  the  archived  LOAD_TABLE 

Chapter  7  SHIP  Software  Modules 


into  a  table  specifically  created  for  this  purpose,  then  seeing  if  the  most 
current  archived  load  already  appears  in  the  database. 

j.  Bulk  copy  data  for  the  six  dynamic  tables  into  the  database  from  the 
archive  files. 

k.  Delete  the  archive  files  on  disk. 

l.  Dump  the  DOSIS  database  (via  script  dosis_dumpdb  which  also  resets 
the  ’select  into’  option).  This  is  done  because  the  select  into  operation 
disables  future  transaction  log  dumps;  so  it  is  necessary  to  dump  the 
entire  database  to  begin  a  new  backup  cycle. 
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The  stored  procedures  used  with  the  Silent  Inspector  software  are  listed 
below  in  bold,  along  with  their  purpose  and  coding.  These  procedures  are 
stored  in  a  file  that  can  be  submitted  to  Sybase  using  interactive  structured 
query  language  (isql).  When  this  file  is  submitted  to  Sybase  via  isql,  any 
existing  stored  procedure  having  the  same  name  is  deleted  and  the  new  proce¬ 
dure  is  created.  The  file  name  is  procscomp.sql,  and  it  can  be  submitted  to 
isql  as  follows: 

isql  <  procscomp.sql 

The  stored  procedures  for  the  Silent  Inspector  system  are: 


INSERT_DOWNTIME_DATA 

Purpose:  Insert  a  downtime  event  in  the  DOWNTIME  table. 
Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  userJdQ  and 
name  =  ’INSERT^DOWNTIME^DATA’  ) 
drop  proc  INSERT_DOWNTIME^DATA 

go 

create  proc  INSERT_DOWNTIME_DATA 
( @CONTRACTJD  CONTRACTJDENTIFIER, 

(©PROJECT  PROJECT^NAME, 

(©DREDGE  DREDGE.NAME, 

@START_DATE_TIME  datetime, 

@END_DATE_TIME  datetime, 

@LOAD_NO  LOAD^NUMBER, 

(g)CAUSE  DOWNTIME.CAUSE, 

(©COMMENT  FREE^FORM^TEXT  )  as 

Insert  into  DOWNTIME 

values 

( @CONTRACTJD, 

(©PROJE<7r, 

@DREDGE, 

@START_DATE_TIME, 

@END^DATE^TIME, 

(©LOAD^NO, 

@CAUSE, 

(©COMMENT  ) 
go 


Appendix  A  Stored  Procedures 


INSERT_DREDGING_DATA 

Purpose:  Insert  dredging  data  in  the  DREDGING  DATA  tabie. 
Code: 

if  exists  (  select  ♦  from  sysobjects  where  uid  =  userJdQ  and 
name  =  ’INSERT.DREDGING^DATA’ ) 
drop  proc  INSERT^DREDGING^DATA 
go 

create  proc  INSERT^DREDGING.DATA 


( (©CONTRACT JD 
@  PROJECT 
@  DREDGE 
@DATE^TIME 
(©VESSEL^X 
@VESSEL_X_STATUS 
@VESSEL^Y 
@VESSEL^Y^STATUS 


CONTRA<rrjDENTIFIER, 

PROJECr^NAME, 

DREDGE^NAME, 

datetime, 

COORDINATE.TYPE, 

STATUS, 

COORDINATE^TYPE, 

STATUS, 


@VESSEL_DRAFT_FORWARD  FEET_TYPE, 
@VESSEL^DRAFT_.FORWARD_STATUS  STATUS, 
(©VESSEL_DRAFT„AFT  FEET.TYPE, 

@VESSEL^DRAFT_AFT_STATUS  STATUS, 
@VESSEL_SPEED  KNOTS.TYPE, 

@VESSEL,SPEED„STATUS  STATUS, 
@VESSEL_HEADING  DEGREES.TYPE, 

@VESSEL_HEADING^STATUS  STATUS, 
@VESSEL^COURSE  DEGREES_TYPE, 

@  VESSEL^COURSE^STATUS  STATUS, 
@DRAGHEAD^DEPTH_PORT  FEET_TYPE, 
(@DRAGHEAD_DEPTH_PORT_STATUS  STATUS, 
<©DRAGHEAD_DEPTH^STBD  FEET^TYPE, 
@DRAGHEAD^DEPTH_STBD_STATUS  STATUS, 
@HOPPER^LEVEL„FORWARD  FEET^TYPE, 
(®HOPPER_^LEVEL^FORWARD_STATUS  STATUS, 
@HOPPER_LEVEL^AFT  FEET.TYPE 

@H0PPER^LEVEL^AFT_STATUS  STATUS 
(SHOPPER^VOLUME  CUBIC_YARDS_TYPE 

@HOPPER_VOLUME_STATUS  STATUS 
(©HOPPER_ULLAGE  FEET_TYPE 

@HOPPER^ULLAGE_STATUS  STATUS 
@WATER_DEPTH  FEET^TYPE 

@WATER_DEPTH_STATUS  STATUS 
@TIDE  FEET^TYPE 

@TIDE_STATUS  STATUS 


@HOPPER^DOOR_OPEN 

(®PUMP_ON^PORT 

@PUMP_ON^STBD 

@PUMP_MATERIAL_PORT 

@PUMP_MATERIAL^STBD 

@PUMP^OUT_ON 


BOOLEAN^TYPE 
B(X)LEAN_TYPE 
B(X)LEAN^TYPE 
BOOLEAN^TYPE 
BOOLEAN^TYPE 
BOOLEAN  TYPE 


@LOAD_NO 

@STATE 

@TDM 


LOAD_NUMBER 
DREDGE_STATE 
LONG  TONS  TYPE 


insert  into  DREDGING_DATA 
values 

( @CONTRACTJD 
(©PROJECT 
@ DREDGE 
@DATE_TIME 
(©VESSEL^X 
(©VESSEL^X.STATUS 
(©VESSEL^Y 
(©VESSEL_Y_STATUS 
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@VESSEL_DRAFT_FORWARD 
(a)VESSEL_DRAFT_FORWARD_STATUS, 
@VESSEL_DRAFT_AFT 
@VESSEL_DRAFT_AFT_STATUS  , 
@VESSEL.SPEED 

@vessel_speed^status 

@VESSEL_HEAD1NG 

@VESSEL_HEADING^STATUS 

@VESSEL^COURSE 

@VESSEL^COURSE_STATUS 

@DRAGHEAD_DEPTH^PORT 

@DRAGHEAD_.DEPTH^PORT^STATUS  , 

@DRAGHEAD^DEPTH_STBD 

@DRAGHEAD_DEPTH_STBD_STATUS  , 

@HOPPER_LEVEL^FORWARD 

@HOPPER_LEVEL_FORWARD^STATUS, 

@HOPPER^LEVEL_AFT 

@HOPPER^LEVEL„AFT_STATUS  , 

@HOPPER_VOLUME 

@HOPPER_VOLUME_STATUS 

@HOPPER„ULLAGE 

@HOPPER.ULLAGE_.STATUS 

@WATER„DEPTH 

@WATER^DEPTH_STATUS 

@TIDE 

@TIDE„STATUS 

@HOPPER_IX)OR_OPEN 

@PUMP^ON^PORT 

@PUMP^ON^STBD 

@PUMP^MATERIAL^PORT 

@PUMP.MATERIAL^STBD 

@PUMP_OUT_ON 

@LOAD^NO 

@STATE 

@TDM  ) 


INSERT^LOAD^DATA 

Purpose:  Insert  summary  data  for  a  load  in  the  LOAD  table. 
Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  user_idO  and 
name  =  ’INSERT_LOAD_DATA*  ) 
drop proc  INSERT.LOAD_DATA 
go 

create  proc  INSERT_LOAD_DATA 
( @CONTRACTJD  CONTRACTJDENTIFIER, 

^PROJECT  PROJECT_NAME, 

@DREDGE  DREDGE_NAME, 

@IjOAD_NO  LOAD^NUMBER, 

@DATE  datetime, 

@  PUMPING^TIME  MINUTES^TYPE, 


@TURNING_TIME  MINUTES_TYPE, 
@SAIUNG_FULL_TIME  MINUTES^TYPE, 

@  DUMPING^TIME  MINUTES_TYPE, 

@SAIUNG„EMPTY„TIME  MINUTES_TYPE, 
(©DOWN-TIME  MINUTES^TYPE, 

@TOTAL_TIME  MINUTES^TYPE, 

@TDM  LONG„TONS_TYPE, 

@COMMENT  FREE_FORM^TEXT  )  as 

insert  into  LOAD  TABLE 
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values 

( @CONTRACTJD, 
@PROJECr, 

@DREDGE, 

@LOAD_NO, 

@DATE. 

@PUMPING^TIME, 

@TURNING^TIME, 

@SAIUNG_FULL_TIME, 

@DUMPING^TIME, 

@SAIUNG_EMPTY_TIME, 

@  DOWN-TIME, 

<aTOTAL_TIME, 

@TDM, 

(©COMMENT ) 


INSERT_LOAD_DISPOSAL_AREA 

Purpose:  Insert  a  dump  event  for  a  rectangular  disposal  area  in  the 
LOAD  DISPOSAL  AREA  table. 

Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  userJdQ  and 
name  =  ’INSERT„LOAD_DISPOSAL_AREA’  ) 
drop  proc  INSERT_LOAD_DISPOSAL^AREA 
go 

create  proc  INSERT^LOAD„DISPOSAL_AREA 
(  @CONTRACT JD  CONTRACTJDENTIH  ER, 

@PROJE(rr  PROJE(rr_NAME, 

@DREDGE  DREDGE_NAME, 

@LOAD^NO  LOAD_NUMBER, 

@DISPOSAL_AREA  AREA_NAME, 


(©DISPOSAL.START^DATE^TIME  datetime  )  as 
insert  into  LOAD_DISPOSAL_AREA 
values 

(  @CONTOACT_ID, 

(©PROJE(7r, 

(©DREDGE, 

@LOAD_NO, 

(©DISPOSAL.AREA, 

(©DISPOSAL_START^DATE_TIME  ) 
go 

INSERT_LOAD  STATION 

Purpose:  Insert  a  dredging  event  for  a  station  (rectagular  dredging  area) 
in  the  LOAD  STATION  table. 

Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  user_idO  and 
name  =  ’INSERT^LOAD.STATION’  ) 
drop  proc  INSERT_LOAD^STATION 
go 

create  proc  INSERT_LOAD_STATION 


(  @CONTRA(rrjD 
@PROJE(7r 
@DREDGE 
@LOAD_NO 
@STAT10N>REA 


CONTRACTJDENTIFIER, 

PROJECriLNAME, 

DREDGE_NAME, 

LOAD_NUMBER, 

AREA^NAME, 


@STAT10N_START^DATE_TIME  datetime  )  as 
insert  into  LOAD  STATION 
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values 

( (©CONTRACT JD, 

(©PROJECT, 

@DREDGE, 

(©LOAD.NO, 

@STATION_AREA, 
(SSTATION_START_DATE^TIME  ) 
go 


INSERT_PROJECT_DREDGE 

Purpose:  Insert  a  dredge  assigned  to  a  project  in  the 

PROJECT_DREDGE  table. 

Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  userJdQ  and 
name  =  ’INSERT_PROJECT_DREDGE’  ) 
drop  proc  INSERT,PROJECT_DREDGE 


go 

create  proc  INSERT_PROJECT_DREDGE 
( (©CONTRACT JD 
(g)  PROJECT 
@ DREDGE 
@CAPTAIN 
@SPEED^TOLERANCE 
(©  DEPTH^TOLERANCE 
@DRAFT_LIMIT 
(©DRAG.LIMIT 
@TRIM^LIMIT 
@TURN^LIMIT 


CONTRACT JDENTIHER, 
PROJECT_NAME, 

DREDGE^NAME, 

CREWJD, 

I^OTS.TYPE, 

FEET_TYPE, 

FEET_TYPE, 

FEET_TYPE, 

FEET_TYPE, 

DEGREES_PER_MINUTE_TYPE, 

(©  DR Y_M ATERI AL^MASS.DENSITY  GRAMS_PER_LITER_TYPE, 
@WATER_MASS_DENSITY  GRAMS„PER^LITER_TYPE, 
@DREDGE^AIDS  FREE^FORM^TEXT, 

(©COMMENT  FREE  JORM^TEXT  )  as 

insert  into  PROJECT_DREDGE 
values 


( (©CONTRACT JD, 

@PROJECT, 

(©DREDGE, 

(©CAPTAIN, 

@SPEED_TOLERANCE, 

@  DEPTH^TOLERANCE, 
@DRAFT^LIM1T, 

(©DRAG^UMIT, 

(g)TRIM^LIMIT, 

@TURN_LIMIT, 

@DRY_MATERIAL^MASS_DENSITY, 

(®WATER_MASS^DENSITY, 

(©DREDGE^AIDS, 

(©COMMENT ) 
go 


INSERT_PROJECT_SUMMARY_DATA 

Purpose:  Insert  a  project  summary  record  in  the  PROJECT  SUMMARY 

table. 

Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  userJdQ  and 

name  =  ’INSERT_PROJECT„SUMMARY^DATA’  ) 
drop  proc  INSERT^PROJECT^SUMMARY^DATA 
go 
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create  proc  INSERT_PROJECT^SUMMARY^DATA 

( (©CONTRACT JD 

CONTRACTJDENTIFIER, 

(©PROJECT 

PROJECr.NAME, 

@DREDGE 

DREDGE^NAME, 

@OPENING^DATE 

datetime, 

(®CLOSING_DATE 

datetime, 

@PUMPING^TIME 

MINUTES.TYPE, 

(©TURNING^TIME 

MINUTES^TYPE, 

@SAIUNG_FULL^TIME 

MINUTES.TYPE, 

@DUMPING^TIME 

MINUTES^TYPE, 

(®SAIUNG_„EMPTY_TIME 

MINUTES_TYPE, 

@  NON.EFFECn  VE_TIME 

MINUTES^TYPE, 

(©LOST^TIME 

MINUTES^TYPE, 

@TO_BE_DEnNED^TIME 

MINUTES_TYPE, 

(SFUEL.AND^SUPPLIES^TIME  MINUTES.TYPE, 

@WHARF_OR_ANCHORAGE_nME  MINUTES_TYPE, 

@OPPOSING_NATURAL_ELEMENT_TIME  MINUTES.TYPE, 

@TRAFFIC_AND„BRJDGES_TIME  MINUTES^TYPE, 

@MINOR_OPERATING_REPAlRS_TIME  MINUTES.TYPE, 

@TRANSFER_BETWEEN_WORKS_TIME  MINUTES_TYPE, 

@LAY_TIME 

MINUTES.TYPE, 

@nRE_AND_BOAT^DRlLLS^TIME  M1NUTES_TYPE, 

(®MISCELLANEOUS_TIME 

MINUTES^TYPE, 

@major_repairs_time 

MINUTES_TYPE, 

@CESSATION„TIME 

MINUTES^TYPE, 

(©COLUSIONS.TIME 

MINUTES.TYPE, 

@ESTIMATED^COST 

money. 

@JOB_TO_DATE^COST 

money. 

@C0ST_PER^M1NUTE 

money. 

(©TONS_RETAINED 

LONG_TONS_TYPE  )  as 

insert  into  PROJECT^SUMMARY 

values 

( (©CONTRACTJD, 

(©PROJECT, 

@DREDGE, 

(§)OPENING^DATE, 

(©CLOSING^DATE, 

@PUMPING^TIME, 

(@TURNING_TIME, 

(©SAIUNG^FULL^TIME, 

@DUMPING„TIME, 

@SA1LING^EMPTY^T1ME, 

@  NON_EFFECrn  VE_TIME, 

(©LOST.TIME, 

(©TO.BE^DERNED.TIME, 

(©FUEL^AND_SUPPUES_TIME, 

<®WHARF_OR_ANCHORAGE_TIME, 

@OPPOSING_NATURAL^ELEMENT^TIME, 

@TRAFF1C^AND_BRIDGES.T1ME, 

(S  MINOR^OPERATING_REPAIRS_TIME, 

@TRANSFER3ETWEEN_W0RKS^TIME, 

(®LAY_T1ME, 

@  fire^and_boat^drills^time. 

(©  MISCELL  ANEOUS^TIME, 

<®major_repairs_time. 

@CESSATION_TIME, 

(©COLLISIONS_TIME, 

(®ESTIMATED_COST, 

@JOB_TO_DATE_COST, 

@COST_PER_MINUTE, 

(©TONS.RETAINED  ) 

go 
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INSERT_STATE 

Purpose:  Insert  a  state  change  record  for  a  load  in  the  STATE  table. 
Code: 

if  exists  (  select  ♦  from  sysobjects  where  uid  =  userJdQ  and 
name  =  ’INSERT_STATE’  ) 
drop  proc  INSERT_STATE 
go 

create  proc  INSERTJSTATE 

( ©CONTRACTJD  CONTRACTJDENTIHER, 

©PROJECT  PROJECT_NAME, 

©DREDGE  DREDGE_NAME. 

©LOAD_NO  LOAD_NUMBER, 

©START_DATE_TIME  datetime, 

©VESSEL_X  COORDINATE_TYPE, 

©VESSEL.Y  COORDINATE_TYPE. 

©VESSEL_HEADING  DEGREES_TYPE, 

©VESSEL_SPEED  KNOTS_TVPE. 

©VESSEL_DRAFT_FORWARD  raET_TYPE, 

@VESSEL_DRAFT_AFT  FEET_TYPE, 

©PORT_PUMP_STATUS  BOOLE  AN_TYPE, 

©DRAGHEAD_DEPTH_PORT  FEET_TYPE. 

©DRAGHEAD_ELEVATION_PORT  FEET.TYPE, 

©STBD_PUMP_STATUS  BOOLEAN_TYPE, 

@DRAGHEAD_DEPTH_STBD  FEET_TYPE, 

©DRAGHEAD_ELEVATION_STBD  FEET_TYPE, 

©TIDE  FEET_TYPE, 

©STATE  DREDGE.STATE )  as 

insert  into  STATE 
values 

(  ©CONTRACTJD. 

©PROJECT, 

©DREDGE, 

©LOAD_NO, 

@START_DATE_TIME, 

©VESSEL_X, 

©VESSEL_Y, 

©VESSEL.HEADING, 

©VESSEL_SPEED, 

©VESSEL_DRAFT_FORWARD, 

©VESSEL_DRAFT_AFT, 

©PORT_PUMP_STATUS, 

©  DRAGHEAD_DEPTH_PORT, 

©DRAGHEAD_ELEVATION_PORT, 

©STBD_PUMP_STATUS, 

©  DRAGHE  AD_DEPTH_STBD, 

©  DRAGHEAD_ELEVATION_STBD, 

©TIDE, 

©STATE  ) 
go 

SELECT_DISPOSAL_AREA_DISTINCT 

Purpose:  Retrieve  a  unique  disposal  area  having  the  specified 

AREA_NAME  from  the  DISPOSAL_AREA  table. 

Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  userJdQ  and 

name  =  ’SELECT_DISPOSAL_AREA_DlSTINCr  ) 
drop  proc  SELECT_DISPOSAL_AREA_DISTINCT 
go 
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create  proc  SELECT_DISP0SAL_AREA_D1STINCT  { @NAME  AREA_NAME  )  as 
select  BOUNDARY_01_X,  BOUNDARY_01_Y,  BOUND ARY_02_X,  BOUNDARY_02_Y, 
BOUNDARY  03_X.  BOUND ARY_03_Y,  BOUNDARY_04_X.  BOUNDARY_04_Y, 
boundaryIo5_x,  BOUNDARY_05_Y,  BOUNDARY_06_X,  BOUNDARY_06_Y. 
BOUNDARY_07_X.  BOUNDARY_07_Y.  BOUNDARY_08_X,  BOUND ARY_08_Y. 
BOUNDARY_09_X,  BOUNDARY_09_Y,  BOUNDARY_10_X,  BOUNDARY_10_Y 
from  DISPOSAL_AREA 
where  NAME  =  ©NAME 
g« 

SELECT_DOWNTIME_DISTINCT 

Purpose:  Retrieve  a  unique  downtime  event  having  the  specified 

CONTRACTJD.  PROJECT,  DREDGE  and 
START  DATEJME  from  the  DOWNTIME  table. 

Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  userJdQ  and 
name  =  ’SELECT_DOWNTIME_DlSTINCT’  ) 
drop  proc  SELECT_DOWNTlME_DlSTINCT 
go 

create  proc  SELECT_DOWNTlME_DlSTINCr 
( ©CONTRACTJD  CONTRACTJDENTIFIER, 

©PROJECT  PROJECT_NAME, 

©DREDGE  DREDGE_NAME, 

©START_DATE_TIME  datetime  )  with  recompile  as 
select  END_DATE=conveit{  chaff 6),  END_DATE_T1ME,  12  ), 

END_TIME=convert(  float,  60  *  60  *  datepart(lth,END_DATE_TIME)  + 

60  *  datepart(mi,END_DATE_TlME)  + 
datepart(ss,END_DATE_TlME)  + 

.001  *  datepart(ms,END_DATE_TlME)  ), 

LOAD_NO.  CAUSE,  COMMENT 
from  DOWNTIME 

where  CONTRACTJD  =  ©CONTRACTJD 

and  PROJECT  =  ©PROJECT 

and  DREDGE  =  ©DREDGE 

and  START_DATE_T1ME  =  ©START_DATE_TIME 

go 

SELECT_LATEST_DREDGING_DATA 

Purpose:  Retrieve  the  record  having  the  latest  dateltime  from  the 

DREDGING _DATA  table. 

Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  userJdQ  and 

name  =  ’SELECT^LATEST.DREDGING^DATA’  ) 
drop  proc  SELECT_LATEST_DREDGING_DATA 

go 

create  proc  SELECT_LATEST_DREDGING_DATA  with  recompile  as 
select  CONTRACTJD, 

PROJECT, 

DREDGE, 

convert(  char(6),  DATE_TIME,  12  ), 

coiivert(  float,  60  *  60  *  datepan(hh,DA'rc_TIME)  + 

60  ♦  datepart(mi,DATE_TJME)  + 
datepart(ss,DATE_TIME)  + 

.001  *  datepart(ms,DATE_TlME) ), 

VESSEL_X, 

VESSEL^X.STATUS, 

VESSEL_Y, 

VESSEL_Y„STATUS, 
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VESSEL.DRAFT^FORWARD, 

VESSEL_DRAFT_FORWARD_STATUS, 

VESSEL^DRAFT^FT, 

VESSEL^DRAFT_AFT^STATUS, 

VESSEL.SPEED, 

VESSEL^SPEED^STATUS, 

VESSEL_HEADING. 

VESSEL^HEADING.STATUS, 

VESSEL_COURSE, 

VESSEL^COURSE.STATUS, 

DRAGHEAD^DEPTH^PORT, 

DRAGHEAD^DEPTH.PORT^STATUS, 

DRAGHEAD^DEPTH.STBD, 

DRAGHEAD^DEPTH_STBD„STATUS, 

HOPPER_LEVEL_FORWARD, 

HOPPER^LEVEL_FORWARD_STATUS, 

HOPPER^LEVEL.AFT, 

HOPPER^LEVEL_AFT_STATUS, 

HOPPER_VOLUME, 

HOPPER_,VOLUME_STATUS, 

HOPPER_ULLAGE, 

HOPPER_ULLAGE_STATUS, 

WATER_.DEPTH, 

WATER_DEPTH_STATUS, 

TIDE, 

TIDE_STATUS, 

HOPPER^DOOR^OPEN, 

PUMP_.ON^PORT, 

PUMP^ON_STBD, 

PUMP^MATERIAL_PORT, 

PUMP^MATERIAL.STBD, 

PUMP_OUT_ON, 

LOADING, 

STATE, 

TDM 

from  DREDGING^DATA 
where  DATE_TIME  = 

(  select  max(DATE_TIME) 
from  DREDGING^DATA  ) 

go 

SELECT_LOAD_DISTINCT 

Purpose:  Retrieve  a  unique  load  record  having  the  specified 

CONTRACT  ID,  PROJECT,  DREDGE  and  LOAD  NO  from 
the  LOAD  table. 

Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  user_idO  and 
name  =  *SELECT^LOAD_DISTINCT^  ) 
drop  proc  SELECT^LOAD^DISTINCT 
go 

create  proc  SELECT_LOAD_DISTINCT 
( @CONTRACTJD  CONTRACT.IDENTIFIER, 

(®  PROJECT  PRO  JECT_N  AME, 

@  DREDGE  DREDGE.NAME, 

<®LOAD_NO  LOAD_NUMBER  )  with  recompile  as 
select  START_DATE=convert(  char(6),  DATE,  12  ), 

STARTjnME=convert(  float,  60  *  60  *  datepartOili,DATE)  + 

60  *  datepart(nii,DATE)  + 
datepart(ss,DATE)  + 

.001  *  datepart(ms,DATE)  ), 
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PUMPING^TIME,  TURNING^TIME,  SAIUNG^FULL^TIME,  DUMPING^TIME, 
SAIUNgJmPTY.TIME,  down-time,  T0TAL_TIME,  TDM,  COMMENT 
fmm  LOAD^TABLE 


where  CONTRACTJD 
and  PROJECT 
and  DREDGE 
and  LOAD.NO 

go 


=  @CONTRACrrjD 
=  @PROJECT 
=  @DREDGE 
=  (©LOADING 


SELECT_MIN_MAX_DATE  TIME 

Purpose:  Retrieve  the  minimum  and  maximum  dateltimes  that  exist  in 

records  in  the  DREDGING  J)ATA  table. 

Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  userJdQ  and 
name  =  ’SELECT_MIN_MAX_DATE^TIME’  ) 
drop  proc  SELECr_MIN_MAX_DATE_TIME 
go 

create  proc  SELECT_MIN_MAX_DATEjnME 
( (©CONTRACTJD  CONTRACT JDENTIHER, 

@  PROJECT  PROJECT^NAME, 

@  DREDGE  DREDGE^NAME  )  with  recompile  as 

select  MIN_DATE=convert(char(6)4nin(DATEjnME),12), 

MIN_TlME=convert(float,60*60*datepartGih,min(DATE_TlME))  + 
60*datepart(mm4nin(DATE_TIME))  + 
datepart(ss4nin(DATE_TIME))  + 
0.001*d^epart(ms,min(DATE_TIME))), 

M  AX_D  ATE=convert(char(6)4nax(D  ATE_TIME),  1 2), 
MAX_TIME=convert(float,60*60*datepart(hh,niax(DATE_TlME))  + 
60^datepart(mm4nax(DATE_TIME))  + 
datepart(ss,max(DATE_TIME))  + 

0.00  l*datepart(ms, max  (DATE_TIME))) 
from  DREDGING_DATA 

where  CONTRACTJD  =  @ CONTRACTJD 

and  PROJECT  =  @  PROJECT 

and  DREDGE  =  @DREDGE 

go 


SELECT_PROCESSED_DREDGING_DATA 

Purpose:  Retrieve  the  record  having  the  latest  dateltime  that  has  been 

processed  (been  assigned  a  state)  by  the  RTJKernel  program 
from  the  DREDGING  _D  AT  A  table. 

Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  user^idQ  and 

name  =  ’SELECT.PROCESSED_DREDGING^DATA’  ) 
drop  proc  SELECT^PROCESSED^DREDGING.DATA 
go 

create  proc  SELECT_PR(X!ESSED_DREDGING_DATA  with  recompile  as 
select  CONTRACTJD, 

PROJECT, 

DREDGE, 

convert(  char(6),  DATELTIME,  12  ), 

convett(  float,  60  ♦  60  *  datepari(hh,DATE_TIME)  + 

60  *  datepart(mi,DATE_TlME)  + 
dalepart(ss,DATE_TlME)  + 

.001  *  datepart(ms,DATE_TlME)  ), 

VESSEL^X, 

VESSEL^X^STATUS, 

VESSEL_Y, 

VESSEL.Y^STATUS, 
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VESSEL^DRAFT.FORWARD, 

VESSEL_DRAFT_FORWARD_STATUS, 

VESSEL_DRAFT_AFT. 

VESSEL.DRAFT^AFT^STATUS, 

VESSEL^SPEED, 

VESSEL^SPEED^STATUS, 

vesselheading, 

VESSEL_HEADING_STATUS, 

VESSELCOURSE, 

VESSEL_COURSE^STATUS, 

DRAGHEAD_DEPTH_PORT, 

DRAGHEAD^DEPTH_PORT_STATUS. 

DRAGHEAD_DEPTH_STBD. 

DRAGHEAD^DEPTH^STBD^STATUS, 

HOPPER^LEVELFORWARD, 

HOPPER_LEVELFORWARD_^STATUS, 

HOPPER_LEVEL_AFT. 

HOPPER.LEVELAFT^STATUS, 

HOPPER^VOLUME, 

HOPPER.VOLUME^STATUS, 

HOPPER_ULLAGE, 

HOPPER_ULLAGE_STATUS, 

WATER.DEPTH, 

WATER^DEPTH.STATUS, 

TIDE, 

TIDE.STATUS, 

HOPPER^DOOR^OPEN, 

PUMP.ON^PORT, 

PUMP^ON^STBD, 

PUMP^MATERIALPORT, 

PUMP.MATERIALSTBD, 

PUMP„OUT^ON, 

LOADING, 

STATE, 

TDM 

from  DREDGING_DATA 
where  DATEJTIME  = 

(  select  max(DATE_TIME) 
from  DREDGING^DATA 
where  STATE  is  not  null ) 

go 

SELECT_PROJECT_DISTINCT 

Purpose:  Retrieve  a  unique  project  record  having  the  specified  CON¬ 

TRACT  JD  and  PROJECT_NAME  from  the  PROJECT  table. 
Use  a  Unix  Join  function  with  the  DISTRICT  Table  to  obtain 
the  District  name. 

Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  userJdQ  and 
name  =  ’SELECT^PROJECT^DISTINCT’  ) 
drop  proc  SELECT^PROJECT_DISTINCT 
go 

create  proc  SELECT_PROJECT_DISTINCT 
( (©CONTRACT JD  CONTRACTJDENTIFIER, 

@NAME  PROJECT_NAME  )  as 
select  DISTRICT.NAME,  THE_TYPE,  CONTRACTOR, 
convert  (  char(6)  ,  START_DATE  ,  12  ), 
convert  (  char(6)  ,  FINISH_DATE  ,  12  ) 
from  PROJECT,  DISTRICT 
where  CONTRACTJD  =  @CONTRACTJD 

and  PROJECT.NAME  =@NAME 
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and  DISTRICT.  ABBREVIATION  =  PROJECT.  DISTRICT 
go 

SELECT_PROJ_SUMMARY_DISTINCT 

Purpose:  Retrieve  a  unique  project  summary  record  having  the  specified 

CONTRACTJD,  PROJECT _NAME  and  DREDGE_NAME 
from  the  PROJECT JUMM ARY  table. 

Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  uscr_idO  and 

name  =  ’SELECT„PROJ_SUMMARY^DlSTlNCT*  ) 
drop  pioc  SELECT^PROJ_SUMMARY_DISTINCT 
go 

create  proc  SELECT^PROJ.SUMMARY^DISTINCT 
( @CONTRACTJD  CONTRACT JDENTIFIER, 

©PROJECT  PROJECT^NAME, 

©DREDGE  DREDGE^NAME )  as 

select  OPENING_DATE=conveit(  char(6),  OPENING^DATE,  12  ), 

CLOSING_DATE=convert(  char(6),  CLOSING.DATE,  12  ), 

PUMPING^TIME,  TURNING^TIME,  SAILING_FULL_TIME,  DUMPING^TIME, 
SAILING^EMPTY_TIME,  NON^EFFECTIVE.TIME,  LOST.TIME, 

TO_BE_DEFINED^TIME,  FUEL^AND.SUPPLIES.TIME,  WHARF_OR^ANCHORAGE_TIME, 

opposing^natural^elements3me,traffic_and_bridges^time, 

MINOR_OPERATING_REPAIRS_TIME,  TRANSFER.BETWEEN^WORKS.TIME, 

LAY.TIME,  FIRE^AND_BOAT_DRILLS^TIME,  MISCELLANEOUS_TIME, 
MAJOR^REPAIRS^TIME,  CESSATION^TIME,  COLLISIONS.TIME, 

ESTIMATED.COST,  JOB.TO^DATE^COST,  COST_PER_MINUTE, 

tons.retaTned 

from  PROJECT^SUMMARY 

where  CONTRACTJD  =  ©CONTRACTJD 

and  PROJECT  =  ©PROJECT 

and  DREDGE  =  ©DREDGE 

go 

SELECT_STATION_DISTINCT 

Purpose:  Retrieve  a  unique  station  (dredging  area)  record  having  the 

specified  AREA_NAME  from  the  STATION  table. 

Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  user_idO  and 
name  =  ’SELECT_STATION_DISTINCT’  ) 
drop  proc  SELECT_STATION_DISTINCT 
go 

create  proc  SELECT_STATION_DISTINCT  (  ©NAME  AREA^NAME  )  as 
select  BOUNDARY_01_X,  BOUNDARY_01^Y,  BOUND ARY_02_X,  BOUNDARY^02„Y, 
BOUNDARY_03^X,  BOUNDARY_03_Y,  BOUNDARY^04_X,  BOUND ARY_04_Y, 
BOUNDARY_05^X,  BOUNDARY_05_Y,  BOUNDARY_06_X,  BOUNDARY_06_Y, 
BOUNDARY„07„X,  BOUND ARY_07_Y,  BOUNDARY_08^X,  BOUND ARY_08_Y, 
BOUNDARY^09^X,  BOUNDARY_09_Y,  BOUNDARY_10_X,  BOUNDARY_10_Y 
from  STATION 
where  NAME  =  ©NAME 

go 

SELECT_UNPROC_DREDGING_DATA 

Purpose:  Retrieve  the  record  having  the  earliest  date/time  that  has  not 

been  processed  (been  assigned  a  state)  by  the  RT  Kernel 
program  from  the  DREDGING  _D AT  A  table. 

Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  user_idO  and 
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name  =  ’SELECT_UNPROC_DREDGING^DATA’  ) 
drop  proc  SELECT_UNPr6c_DREDGING^DATA 
go 

create  proc  SELECT_UNPROC_DREDGING_DATA  with  recompile  as 
select  CONTRACTJD, 

PROJECT, 

DREDGE, 

convert(  char(6),  DATE_TIME,  12  ), 

convert(  float,  60  *  60  *  datepart(hh,DATE_TIME)  + 

60  *  datepart(mi,DATE_TIME)  + 
datepart(ss,DATE_TlME)  + 

.001  *  datepart(ms,DATE_TlME) ), 

VESSEL^X, 

VESSEL^X^STATUS, 

VESSEL_Y, 

VESSEL^Y_STATUS, 

VESSEL_DRAFT_FORWARD, 

VESSEL^DRAFT^FORWARD^STATUS, 

VESSEL_DRAFT_AFT, 

VESSEL„DRAFT_AFT^STATUS, 

VESSEL^SPEED, 

VESSEL.SPEED^STATUS, 

VESSEL^HEADING, 

VESSEL_HEADING_STATUS, 

VESSEL_COURSE, 

VESSEL_COURSE„STATUS, 

DRAGHEAD_DEPTH^PORT, 

DRAGHEAD^DEPTH^PORT.STATUS, 

DRAGHEAD_DEPTH_STBD, 

DRAGHEAD_DEPTH_STBD_STATUS, 

HOPPER_LEVEL_FORWARD, 

HOPPER^LEVEL_FORWARD^STATUS, 

HOPPER.LEVEL^AFT, 

HOPPER_LEVEL^AFT_STATUS, 

HOPPER^VOLUME, 

HOPPER^VOLUME^STATUS, 

HOPPER.ULLAGE, 

HOPPER.ULLAGE^STATUS, 

WATER.DEPTH, 

WATER_DEPTH_STATUS, 

TIDE, 

TIDE.STATUS, 

HOPPER_DOOR_OPEN, 

PUMP_.ON_PORT, 

PUMP_ON_STBD, 

PUMP_MATERlAL^PORT, 

PUMP^MATER1AL_STBD, 

PUMP_OUT^ON, 

LOAD_NO, 

STATE, 

TDM 

from  DREDGING^DATA 
where  DATE_T1ME  = 

(  select  min(DATE_TIME) 
from  DREDGING.DATA 
where  STATE  is  null  ) 
go 

UPDATE_DOWNTIME 

Purpose:  Update  a  downtime  event  in  the  DOWNTIME  table  with  a 

cause  and  comment. 
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Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  userJdQ  and 
name  =  ’UPDATE.DOWNTIME*  ) 
drop  proc  UPDATE^DOWNTIME 

go 

create  proc  UPDATE^DOWNTIME 
( (©CONTRACT JD  CONTRACT JDENTIHER, 

@  PROJECT  PROJECT.NAME, 

@DREDGE  DREDGE.NAME, 

@START_DATE_TIME  datetime, 

©CAUSE  DOWNTIME^CAUSE, 

©COMMENT  FREE_FORM_TEXT  )  with  recompile  as 
update  DOWNTIME 
set  CAUSE  =  ©CAUSE, 

COMMENT  =  ©COMMENT 
where  CONTRACTJD  =  ©CONTRACTJD 
and  PROJECT  =  ©PROJECT 

and  DREDGE  =  ©DREDGE 

and  START_DATE_TIME  =  ©START_DATE_TIME 
go 

UPDATE_DREDGING_DATA 

Purpose:  Update  a  dredging  data  record  in  the  DREDGING_DATA 

table  with  a  load  number,  state  and  TDM. 

Code: 

if  exists  (  select  *  from  sysobjects  where  uid  =  userJdQ  and 
name  =  ’UPDATE_DREDGING^DATA’ ) 
drop  proc  UPDATE_DREDGING_DATA 
go 

create  proc  UPDATE^DREDGING_DATA 
(  ©CONTRACTJD  CONTRACT JDENTIFIER, 

©  PROJECT  PROJECT^N  AME, 

©DREDGE  DREDGE_NAME, 

©DATE_TIME  datetime, 

©LOAD_NO  LOAD_NUMBER, 

©STATE  DREDGE^STATE, 

©TDM  LONG_TONS_TYPE  )  with  recompile  as 

update  DREDGING.DATA 
set  LOADING  =  ©  LOADING, 

STATE  =  ©STATE, 

TDM  =  ©TDM 

where  CONTRACTJD  =  ©CONTOACTJD 
and  PROJECT  =  ©PROJECT 
and  DREDGE  =  ©DREDGE 
and  DATE.TIME  =  ©DATE_TIME 
go 

UPDATE_PROJECT_SUMMARY 

Purpose:  Update  a  project  summary  record  in  the 

PROJECT  SUMMARY  table. 

Code: 

if  exists  ( select  *  from  sysobjects  where  uid  =  user_idO  and 
name  =  ’UPDATE_PROJECT_SUMMARY’  ) 
drop  proc  UPDATE_PROJECT_SUMMARY 
go 

create  proc  UPDATE_PROJECT_SUMMARY 
( ©CONTRACTJD  CONTRACTJDENTIHER, 

©PROJECT  PROJECT.NAME, 

©DREDGE  DREDGE_NAME, 
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@CLOSING^DATE 

datetime. 

@PUMPING_TIME 

MINUTES^TYPE, 

@TURNING^TIME 

MINUTES^TYPE, 

@SAIUNG^FULL_TIME 

MINUTES_TYPE, 

@DUMPING_TIME 

MINUTES.TYPE, 

@SAIUNG_EMPTY_TIME 

MINUTES^TYPE, 

@NON_EFFECnVE^TIME 

MINUTES_TYPE, 

@LOsf^TIME 

MINUTES.TYPE, 

@to_be^defined_time 

MINUTES.TYPE, 

@fuel_and^supplies_time  minutes.type. 

<a>WHARF_OR_ANCHORAGE_TIME  MINUTES_TYPE, 

@OPPOSING_NATURAL^ELEMENT_TIME  MINUTES^TYPE, 

@TRAFFIC_AND_BRIDGES_TIME  MINUTES_TYPE, 

(a)MINOR_OPERATlNG_REPAIRS^TIME  MINUTES.TYPE, 

@TRANSFER_BETWEEN_WORKS_TIME  MINUTES_TYPE, 

@LAY_TIME 

MINUTES.TYPE, 

@nRE_AND_BOAT^DRILLS_TIME  MINUTES.TYPE, 

@MISCELLANEOUS_TIME 

MINUTES^TYPE, 

(S  M  AJOR^REP  AIRS^TIME 

MINUTES^TYPE, 

@CESSATION^TIME 

MINUTES_.TYPE, 

@COLLISIONS_TlME 

MINUTES^TYPE, 

@ESTIMATED_COST 

money » 

@JOB^TO^DATE^COST 

money, 

<a)COST_PER„MINUTE 

money, 

@TONS^RETAINED 

LONG^TONS^TYPE  )  as 

update  PROJECT_SUMMARY 

set  CLOSING^DATE 

=  @CLOSING_DATE, 

PUMPING_TIME 

=  (©PUMPING_TIME, 

TURNING.TIME 

=  @TURNING_T1ME, 

SAIUNG_FULL_TIME 

=  (®SAIUNG_FULL_TIME, 

DUMPING^TIME 

=  @DUMPING^TIME, 

SAIUNG3MPTY_T1ME 

=  @SAIUNG^EMPTY_TIME, 

NON^EFFECTIVE^TIME 

=  @NON^EFFECTIVE_TIME, 

LOST^TIME 

=  @LOST_TIME, 

to^bLdefined.time 

=  @to_be_defined_time. 

FUEL_AND„SUPPLIES_TIME  =  @  FUEL_AND_SUPPLIES_TIME, 

WHARF^OR_ANCHORAGE„TIME  =  @WHARF_OR_ANCHORAGE_TIME, 

OPPOSING_NATURAL„ELEMENTS^TIME  =  @OPPOSING^NATURAL^ELEMENT_TIME, 

TRAFFIC_AND_BRIDGES_TIME  =  @TRAFFIC_AND3RIDGES„TIME, 

MINOR„OPERATING_REPAIRS_TIME  =  @MINOR_OPERATING_REPAIRS_TIME, 

transfer^between^works^time  =  @transfer_between_works_time, 

LAY^TIME 

=  @LAY_TIME, 

FIRE_AND_BOAT_DRILLS_TIME  =  @FIRE^AND30AT„DRILLS„TIME, 

MISCELLANEOUS^TIME 

=  @MISCELLANEOUS_TIME, 

major_repairs_time 

=  @MAJOR_REPAIRS_TIME, 

CESSATION.TIME 

=  (©CESSATION^TIME, 

COLUSIONS^TIME 

=  @COLLISIONS^TIME, 

ESTIMATED.COST 

=  (©ESTIMATED_C0ST, 

JOB_TO^DATE^COST 

=  @JOB^TO^DATE_COST, 

COST_PER^MINUTE 

=  (©COST^PER^MINUTE, 

TONS.RETAINED 

=  @TONS_RETAiNED 

where  CONTRACTJD  =  (©CONTRACT JD 

and  PROJECT  =  (©PROJECT 

and  DREDGE  =@  DREDGE 

go 
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@JOB_TO_DATE_COST  money, 

@COST_PER_MINUTE  money, 

@TONS_RETAINED  LONG_TONS_TYPE  )  as 

update  PROJECT.SUMMARY 

set  CLOSING_DATE  =  @CLOSING_DATE, 

PUMPING.TIME  =  @PUMPING_TIME, 

TURNING_TIME  =  @TURN1NG_TIME, 

SAIUNG_FULL_TIME  =  @SAIUNG_FULL_TIME, 

DUMPING_TIME  =  @DUMPING_TIME, 

SAILING_EMPTY_TIME  =  @SAILING_EMPTY_T1ME, 

NON_EFFECTIVE_TIME  =  @NON_EFFECnVE_TrME, 

LOST_TIME  =  (SLOST.TIME, 

TO_BE_DEFINED_TIME  =  @TO_BE_DEnNED_TIME, 

FUEL_AND_SUPPUES_TIME  =  @FUEL_AND_SUPPL1ES_T1ME, 

WHARF_OR_ANCHORAGE_TIME  =  @WHARF_OR_ANCHORAGE_TIME, 
OPPOSING_NATURAL_ELEMENTS_TIME  =  @OPPOSING_NATURAL_ELEMENT_TIME, 
TRAFFIC_AND_BRIDGES_TIME  =  @TRAFFIC_AND_BR1DGES_TIME, 
M1N0R_0PERAT1NG_REPAIRS_TIME  =  @MINOR_OP^TING_REPAIRS_TIME, 
TRANSFER_BETWEEN_WORKS_TlME  =  @TRANSFER_BETWEEN_W0RKS_T1ME, 
LAY_TIME  =  @LAY_TIME, 

FIRE_AND_BOAT_DRILLS_TIME  =  @nRE_AND_BOAT_DRILLS_TIME, 
MISCELLANEOUS_TIME  =  @M1SCELLANE0US_T1ME, 

MAJOR_REPAIRS_TIME  =  @MAJOR_REPAIRS_TIME, 

CESSATION.TIME  =  @CESSATION_TIME, 

COLUSIONS_TIME  =  @C0LLIS10NS_TIME, 

ESTIMATED_COST  =  @ESTIMATED_CX)ST, 

JOB_TO_DATE_COST  =  @JOB_TO_DATE_COST, 

COST_PER_MlNUTE  =  @COST_PER_MINUTE, 

TONS_RETAINED  =  @TONS_RETAINED 

where  CONTRACTJD  =  @CONTRACT_ID 
and  PROJECT  =  ©PROJECT 

and  DREDGE  =  ©DREDGE 

go 
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Backup  and  Archive  Script 


ARCHIVE  FUNCTION  SCRIPTING 

#!csh 

# 

#  dosis_archive  -  write  archive  files  to  $DOSlS_ARCHIVE,  remove  archived  data 

#  from  the  database 

# 

unset  noclobber 

# 

#  make  sure  all  required  environment  variables  are  set  correctly 

# 

if  (  $?DOSIS_COMMAND_DIR  ==  0  )  then 
echo  "Environment  variable  DOSISjCOMMAND_DIR  not  set;  please  set  and  rerun" 
set  DOSIS^COMMAND^DIR  =  dummy 
exit(l) 

else  if  (  -d  $DOSIS_COMMAND„DIR  ==  0  )  then 
echo  "Environment  variable  IX)SIS_COMMAND_DIR  does  not  designate  a  directory" 
echo  "  Please  set  and  rerun" 
exit(l) 
endif 

if  (  -e  $DOSIS_COMMAND_DIR/check„vars  ==  0  )  Uien 
echo  "$DOSIS_COMMAND_DIR/check_vars  script  does  not  exist" 
echo  "  Please  fix  and  rerun" 
exit(l) 
endif 

sou  rce  $E)OSIS_COMMA  ND_DIR/check_vars 
if  (  $status  1=  0  )  exit(l) 

# 

#  make  sure  an  archive  hasnH  already  been  taken  today 

# 

if  (  -e  $DOSlS_ARCHIVE/$date$ArchiveTables[2].ad  ==  1  )  then 
echo  "An  archive  has  already  been  taken  today.  Please  wait  for  tomorrow" 
exit(l) 
endif 
# 

#  dump  the  transaction  log  before  starting  the  archive 

# 

if  (  -e  $DOSIS_COMMAND_DIR/dosis_dumptran  ==  0  II  \ 

-e  $DOSIS_COMMAND_DIR/dosis_dumpdb  ==  0  )  then 
echo  "CanH  find  $DOSIS_COMMAND_DIR/dosis_dumptran  and/or  dosis_dumpdb  scripts" 
echo  "  Please  fix  and  rerun" 
exit(l) 
endif 
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source  $DOSIS_COMMA ND_DIR/dosi s_dumptran 
if  (  $status  !=  0  )  exit(l) 

# 

#  set  options  to  allow  us  to  select  into,  etc. 

# 

isql  -Usa  >P$SA^PASSWORD  «EX1T  >DOSIStemp 
sp_dboption  EKDSIS,  selec,  true 
go 

sp^dboption  DOSIS,  trunc,  true 
go 

use  DOSIS 
go 

checkpoint 

go 

EXIT 

diff  DOSlStemp  -  >/dev/null  «EX1T 

Run  the  CHECKPOINT  command  in  the  database  that  was  changed. 

(return  status  =  0) 

Run  the  CHECKPOINT  command  in  the  database  tliat  was  changed. 

(return  status  =  0) 

EXIT 

if  (  Sstatus  !=  0  )  then 

echo  "Unable  to  set  database  options:  please  correct  below  errors  and  rerun" 
cat  DOSlStemp 

csh  $DOSIS_COMMAND_DIR/dosis_dumpdb 
exit(l) 
endif 
# 

#  bulk  copy  the  required  tables 

# 

isql  -Usa  -P$SA_PASSWORD  «EXIT  >DOSIStemp 
use  IX)SIS 
go 

select  "marker",  max(LOAD_NO) 
from  LO  A  DATABLE 
go 

EXIT 

set  return  =  ‘grep  marker  DOSlStemp* 
if  (  $#retum  =  0  )  then 

echo  "Can’t  read  max  load  number,  please  correct  below  errors  and  rerun" 
cat  DOSlStemp 

csh  $DOSIS_COMMAND_DIR/dosis_dumpdb 
exit(l) 
endif 

set  MaxLoadNo  =  $retum[2] 
if  (  SMaxLoadNo  ==  "NULL"  )  then 
echo  "No  loads  have  been  completed;  please  rerun  archive  request  later" 
csh  $DOSlS_COMMAND_DIR/dosis_dumpdb 
exil(l) 
endif 

set  WorkArchiveTables  =  (  $ArchiveTables  ) 

while  (  $#WoikArchiveTables  !=  0  ) 

isql  -Usa  -P$SA_PASSWORD  «EXIT  >DOSISlemp 

use  DOSIS 

go 

if  exists  (  select  *  from  sysobjects  where  name  =  "ArchiveTemp"  ) 
drop  table  ArchiveTemp 

go 

select  * 

into  ArchiveTemp 

from  $WorkArchiveTabIes[l] 
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where  LOAD_NO  <=  $MaxLoadNo 

go 

declare  @OriginalCount  int,  @CopiedCount  int 
select  (©OriginalCount  =  count(*) 
from  $WoikArchiveTables[l] 
where  LOAD_NO  <=  $MaxLoadNo 
select  @CopiedCount  =  count(*) 
from  ArchiveTemp 
if  (  @OriginalCount  =  @CopiedCount  ) 
select  "SUCCESS",  @CopiedCount 
go 

EXIT 

set  return  =  *grep  SUCCESS  DOSIStemp* 
if  (  $#retum  =  0  )  then 
echo  "Could  not  copy  table  for  bulk  copy" 
echo  "  Please  correct  below  errors  and  rerun" 
cat  DOSIStemp 

im  $DOSIS^ARCHIVE/$date*.ad 
csh  $lX)SIS_COMMAND_DIR/dosis_dumpdb 
exit(l) 
endif 

set  RowCount  =  $retum[2] 

bcp  DOSlS.dbo.ArchiveTemp  out  $DOSlS_ARCHIVE/$date$WorkArchiveTables(2].ad  \ 
-n  -Usa  -P$SA_PASSWORD  >DOSIStemp 
set  return  =  ‘grep  "rows  copiecK"  DOSIStemp* 
if  (  $#retum  =  0  )  then 

echo  "Bulk  copy  out  failed  -  please  correct  below  errors  and  rerun" 
cat  DOSIStemp 

im  $DOSlS_ARCHIVE/$date*.ad 
csh  $DOSIS_COMMAND_DIR/dosis_dumpdb 
exil(l) 
endif 

if  (  $retum[l]  !=  $RowCount  )  then 

echo  "Wrong  row  count  on  bulk  copy  out  -  please  check  below  errors  and  rerun" 
cat  DOSIStemp 

im  $DOSIS_ARCHIVEy$date*.ad 
csh  $DOSlS_COMMAND_DIR/dosis_dumpdb 
exit(l) 
endif 

shift  WoikArchiveTables 
shift  WorkArchiveTables 
shift  WorkArchiveTables 
end 
# 

#  delete  the  archived  data 

# 

set  WorkArchiveTables  =  (  $ArchiveTables  ) 

while  (  $#WorkArchiveTables  !=  0  ) 

isql  -Usa  -P$SA_PASSWORD  «EX1T  >DOSIStemp 

use  DOSIS 

go 

delete  $WorkArchiveTables[l] 
where  LOAD_NO  <=  $MaxLoadNo 
go 

EXIT 

set  return  =  ‘grep  affected  DOSIStemp* 
set  return  1  =  *grep  Msg  DOSIStemp* 
if  (  $#retum  =  0  II  $#retuml  !=  0  )  then 
echo  DELETE  FAILED  FOR  ARCHIVED  DATA  *♦***" 

echo  YOUR  DOSIS  DATABASE  MAY  NOW  BE  INCONSISTENT 

echo  "*****  WE  STRONGLY  RECOMMEND  RUNNING  dosis^restore  NOW  *****" 
echo  "*****  see  below  errors  ***★*« 

cat  IX)SIStemp 
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endif 

shift  WoikArchiveTables 
shift  WorkArchiveTables 
shift  WorkArchiveTables 
end 
# 

#  Done  -  report  success,  dmnp  the  database 

# 

echo  "Archive  files  for  $date  have  been  created" 
csh  $DOSlS_COMMAND_DIR/dosis_dumpdb 
exit(O) 


CHECKING  FUNCTION  FOR  ARCHIVING  SCRIPTING 

#!csh 

# 

#  cbeck__vars  -  make  sure  all  environment  variables  are  set  for  DOSIS  scripts 

# 

#  tables  to  archive 

# 

set  ArchiveTables  =  ( \ 

DREDGING^DATA  DDA  DATE^TIME  \ 

STATE  STA  START_DATE_TIME  \ 

LOAD^TABLE  LDT  DATE  \ 

DOWNTIME  DWN  START_DATE^T1ME  \ 

LOAD_DISPOSAL_AREA  LDA  DISPOSAL_START_DATE_TIME  \ 
LOAD^STATION  LST  STATION^START^DATE^TIME  ) 

# 

#  make  sure  all  required  environment  variables  are  set  correctly 

# 

set  DiskDumpDevice  =  2 
unset  noclobber 
set  error  =  0 

if  (  $?SA^PASSWORD  ==  0  )  then 

echo  "Environment  variable  SA_PASSWORD  not  set;  please  set  and  rerun" 
set  error  =  1 
else 

isql  -Usa  -P$SA_PASSWORD  «EXIT  >DOSIStemp 
select  1234 

go 

EXIT 

set  retum=‘grep  1234  DOSIStemp‘ 
if  (  $retum  !=  1234  )  then 

echo  "Environment  variable  SA_PASSWORD  is  not  correct  sa  password" 
echo  "  Please  set  and  reran" 
set  error  =  1 
endif 
endif 

if  (  $?DOSIS^ARCHIVE  ==  0  )  then 

echo  "Environment  variable  DOSIS_ARCHIVE  not  set;  please  set  and  rerun" 
set  DOSIS^ARCHIVE  =  dummy 
set  error  =  1 

else  if  (  -d  $DOSIS_ARCHIVE  ==  0  )  then 
echo  "Environment  variable  DOSIS_ARCHIVE  does  not  designate  a  directory" 
echo  "  Please  set  and  reran" 
set  error  =  1 
endif 

if  (  $?DOSIS3ACKUP  ==  0  )  then 

echo  "Environment  variable  DOSIS_BACKUP  not  set;  please  set  and  rerun" 
set  DOSIS_BACKUP  =  dummy 
set  error  =  1 

else  if  (  -d  $D0S1S_BACKUP  ==  0  )  then 
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echo  "Environment  variable  E)OSIS_BACKUP  does  not  designate  a  directory" 
echo  "  Please  set  and  rerun" 
set  error  =  1 
endtf 

if  (  $?DOSIS^COMMAND^DIR  ==  0  )  then 
echo  "Environment  variable  DOSIS_COMMAND_DIR  not  set;  please  set  and  remn" 
set  DOSIS_COMMAND_DIR  =  dummy 
set  error  =  1 

else  if  (  -d  $DOSIS^COMMAND_DIR  =  0  )  then 
echo  "Environment  variable  IX)S1S_C0MMAND_DIR  does  not  designate  a  directory" 
echo  "  Please  set  and  remn" 
set  error  =  1 
endif 

if  (  $?DOSIS^DUMP^DEVICE  =  0  )  then 
echo  "Envirormient  variable  DOS IS_DUMP_DE VICE  not  set;  please  set  and  rerun" 
set  error  =  1 
else 

isql  -Usa  -P$SA_PASSWORD  -w256  «EXIT  >DOSIStemp 
select  "marker",  cntrltype,  phyname 
from  sysdevices 

where  name  =  "$DOSIS_DUMP_DEVICE" 

go 

EXIT 

set  return  =  ‘grep  marker  DOSIStemp* 
if  (  $#retum  =  0  )  then 

echo  "Environment  variable  DOSIS_DUMP_DEVICE  not  set  to  a  valid  dump  device" 
echo  "  Please  set  and  reran" 
set  return  =  (22  2  ) 
set  error  =  1 
endif 

if  (  $retum[2]  !=  $DiskDumpDevioe  )  then 

echo  "Environment  variable  DOSIS_DUMP_DEVICE  not  set  to  a  valid  dump  device" 
echo  "  Please  set  and  reran" 
set  error  =  1 
endif 

set  IX)SIS_DUMP_FILE  =  $retum[3] 
endif 

if  (  $error  =  1  )  exit(l) 

# 

#  establish  date  for  file  names  and  archive  time 

# 

set  date=‘date  +’%y%m%d** 
if  (  $date  <  *500000’  )  then 
set  date  =  20$ {date} 
else 

set  date  =  19$ {date} 
endif 
exit(O) 


DELETE  ARCHIVED  nLES  FUNCTION  SCRIPTING 

#!csh 

# 

#  dosis_clean  [  yyyymmdd  ]  -  delete  archive  files  from  yyyymmdd  (if  specified), 

#  else  oldest  archive  set 

# 

unset  noclobber 
# 

#  make  sure  all  required  environment  variables  are  set  correctly 

# 

if  (  $?DOSIS_COMMAND_DIR  ==  0  )  then 
echo  "Environment  variable  DOSlS_COMMAND_DIR  not  set;  please  set  and  rerun" 
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set  DOSIS_COMMAND_DIR  =  dummy 
exil(l) 

else  if  (  -d  $DOSIS_COMMAND_DIR  ==  0  )  then 
echo  "Environment  variable  IX)SIS_COMMAND_DIR  does  not  designate  a  directoiy" 
echo  "  Please  set  and  rerun" 
exit(l) 
endif 

if  (  -e  $DOSIS_COMMAND_DIR/check_vars  ==  0  )  then 
echo  "$DOSIS_COMMAND_DIR/check_vars  script  does  not  exist" 
echo  "  Please  fix  and  rerun" 
exit(l) 
endif 

source  $E)OSIS_COMMAND_DIR/check_vars 
if  (  $status  !=  0  )  exit(l) 

# 

#  get  date  either  from  (a)  our  argument  or  (b)  oldest  archive  file 

# 

if  (  $#argv  =  0  )  then 

set  Date  =  (  $DOSIS_COMMAND_DIR/check*_vars  $DOSlS_ARCHlVE/*.ad  ) 
shift  Date 

if  (  $#Date  =sss  0  )  then 

echo  "No  archive  files  are  present  No  need  to  clean  them  out" 
exit(l) 
endif 

awk  *{  print  substr($l,l»8)  }’  «EX1T  >DOSISlemp 
$DateIll:t 
EXIT 

set  Date  =  ‘cat  DOSIStemp* 
else 

set  Date  =  $argv[l] 
endif 
# 

#  make  sure  at  least  one  archive  files  exists 

# 

set  WorkArchiveTables  =  (  $ArchiveTables  ) 
unset  exists 

while  (  $#WorkArchiveTables  !=  0  ) 
set  filename  =  $DOSlS^ARCHIVE/$Date$ WorkArchiveTables [2]. ad 
if  (  -e  Sfilename  )  then 
set  exists  =  1 
rm  $filename 
endif 

shift  WorkArchiveTables 
shift  WorkArchiveTables 
shift  WorkArchiveTables 
end 

if  (  $?cxists  ==  0  )  then 

echo  "No  archive  files  found  for  that  date.  Please  rerun  with  correct  date" 
exit(l) 
endif 

echo  "Archive  files  for  $Date  deleted" 
exit(O) 


DUMP  DOSIS  DATABASE  FUNCTION  SCRIPTING 

#!csh 

# 

#  dosis_dumpdb  -  dump  DOSIS  database,  also  delete  all  but  latest  database  and 

#  transaction  log  dumps 

# 

unset  noclobber 
# 
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#  make  sure  all  required  environment  variables  are  set  correctly 

# 

if  (  $?DOSlS_COMMAND_^DIR  ==  0  )  then 
echo  ’’Environment  variable  IX)SIS_COMMAND_DIR  not  set;  please  set  and  rerun" 
set  E)OSIS_COMMAND_DIR  =  dummy 
exit(l) 

else  if  (  -d  $DOSlS_COMMAND^DIR  =  0  )  then 
echo  ’’Environment  variable  DOSlS_COMMAND_DIR  does  not  designate  a  directory" 
echo  ”  Please  set  and  remn" 
exit(l) 
endif 

if  ( -e  $DOSIS_COMMAND_DIR/chedc_vars  ==  0  )  then 
echo  ’’$DOSIS_COMMAND_DIR/check_vars  script  does  not  exist" 
echo  ’’  Please  fix  and  rerun" 
exit(l) 
endif 

source  $DOSlS_COMMAND_DIR/check_vars 
if  (  $status  !=  0  )  exit(l) 

# 

#  delete  old  backups 

# 

set  DatabaseDumps  =  (  $DOSIS„COMMAND_DIR/check*_vars  $DOSIS_BACKUP/*.dbd  ) 

shift  DatabaseDumps 

while  (  $#DatabaseDumps  >  1  ) 

set  LogDumps  =  (  $DOSIS_COMMAND_DIR/check*_vars  $DOSIS_BACKUP/*.Ud  ) 
shift  LogDumps 
while  (  $#LogDumps  >  0  ) 
sort  «EXIT  >DOSIStemp 
$LogDumps[l]:r 
$DatabaseDumps[2]:r 
EXIT 

set  return  =  ‘cat  DOSIStemp* 
if  (  $retum[l]  ==  $LogDumps[l]:r  )  then 
rm  $LogDumps[l] 
else 
break 
endif 

shift  LogDumps 
end 

mi  $Databa$eDumps[l] 
shift  DatabaseDumps 
end 
# 

#  fmd  the  suffix  for  the  database  dump 

# 

if  (  -e  $DOSIS„BACKUP/${date)z.dbd  )  then 
echo  "Too  many  dumps  taken  today.  Please  check  $DOSIS_BACKUP" 
exit(l) 
endif 

set  prev_suffix  =  z 

foreach  suffix  (yxwvutsrqponmlkjihgfedcba) 
if  ( -e  $DOSIS_BACKUP/$date$suffix.dbd  )  then 
set  suffix  =  $prev_suffix 
break 
endif 

if  ( -e  $DOSIS„BACKUP/$date$suffix.tld  )  break 
set  prev_suffix  =  Ssuffix 
end 
# 

#  set  options  and  truncate  the  transaction  log  in  preparation  for  dumping 

# 

isql  -Usa  -P$SA_PASSWORD  «EX1T  >DOSIStemp 
sp_dboption  DOS  IS,  selec,  false 
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go 

sp_(ftK)ption  DOSIS,  Irunc,  false 

go 

use  DOSIS 
go 

checkpoint 

go 

dump  transaction  DOSIS  with  tnincate_only 
go 

EXIT 

diff  DOSIStemp  -  >/dev/nuU  «EXIT 

Run  the  CHECKPOINT  command  in  the  database  that  was  changed, 
(return  status  =  0) 

Run  the  CHECKPOINT  command  in  the  database  that  was  changed, 
(return  status  =  0) 

EXIT 

if  (  Sstatus  1=  0  )  then 

echo  ''Unable  to  set  database  options  and  truncate  transaction  log" 
echo  "  Hease  correct  below  errors  and  rerun" 
cat  DOSIStemp 
exit(l) 
endif 
# 

#  dump  the  database 

# 

if  (  -e  SDOSIS^DUMP^FILE  )  nn  $DOSIS„DUMP_FILE 
isql  -Usa  -PSSA^PASSWORD  «EX1T  >DOSIStemp 
dump  database  DOSIS  to  $DOSIS_DUMP_DEVICE 
go 

EXIT 

set  return  =  ‘cat  DOSIStemp* 

if  (  $#retum  !=  0  II  -e  $DOSIS^DUMP_FILE  ==  0  )  then 
echo  "Database  dump  failed  -  please  correct  below  errors  and  rerun" 
cat  DOSIStemp 
exit(l) 
endif 

set  filename  =  $DOSIS_BACKUP/$date$suffix,dbd 
mv  $DOSIS_DUMP_FILE  $filename 
if  ( -e  Sfilename  !=  1  )  then 

echo  "Failed  to  copy  database  dump  --  please  correct  and  rerun" 
exit(l) 
endif 
# 

#  success  message 

# 

echo  "DOSIS  database  dumped  to  $filename" 
exit(0) 


DUMP  DOSIS  DATABASE  TRANSACTION  LOG  FUNCTION 
SCRIPTING 

#!csh 

# 

#  dosis_dumptran  >  dump  DOSIS  database  transaction  log 

# 

unset  noclobber 
# 

#  make  sure  all  required  environment  variables  are  set  correctly 

# 

if  (  $?DOSIS_COMMAND_DIR  ==  0  )  then 
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echo  "Environment  variable  DOSIS_COMMAND_DIR  not  set;  please  set  and  rerun" 

set  IX)SISjCOMMAND_DIR  =  dununy 

exit(l) 

else  if  (  -d  $E)OSlS_COMMAND_,DIR  =  0  )  then 
echo  "Environment  variable  DOSIS_COMMAND_DlR  does  not  designate  a  directory" 
echo  "  Please  set  and  rerun" 
exit(l) 
endif 

if  ( -e  $DOSIS_COMMAND^DIR/check_vars  ==  0  )  then 
echo  "$DOSIS_COMMAND_DIR/check_vars  script  does  not  exist" 
echo  ”  Please  fix  and  rerun" 
exit(l) 
endif 

source  $DOSIS__COMMAND_DIR/check_vars 
if  (  $status  !=  0  )  exit(l) 

# 

#  find  the  suffix  for  the  transaction  log 

# 

if  (  -e  $DOSIS3ACKUP/${date}z.dbd  II  -e  $DOSIS3ACKUP/${date}z.ad  )  then 
echo  "Too  many  dumps  taken  today.  Please  check  $DOSIS_BACKUP" 
exit(l) 
endif 

set  prcv_suffix  =  z 

foreach  suffix  (yxwvutsrqponmlkjihgfedcba) 
if  ( -e  $DOSIS3ACKUP/$date$suffix.dbd  II  \ 

-e  $DOSIS_BACKUP/$date$suffix.Ud  )  then 
set  suffix  =  $prev_suffix 
break 
endif 

set  prev_suffix  =  $suffix 
end 
# 

#  dump  the  transaction  log 

# 

if  ( -e  $DOSIS^DUMP_FILE  ==  1  )  mi  $DOSIS_DUMP_FILE 
isql  -Usa  -P$SA_PASSWORD  «EXIT  >DOSIStemp 
dump  transaction  DOSIS  to  $DOSlS_DUMP__DEVlCE 

go 

EXIT 

set  return  =  *cat  DOSIStemp* 

if  (  $#retum  !=  0  II  -e  $DOSIS^DUMP^FILE  ==  0  )  then 
echo  "Transaction  log  dump  failed  -  please  correct  below  errors  and  reran" 
cat  EKDSIStemp 
exit(l) 
endif 

set  filename  =  $DOSIS_BACKUP/$date$suffix.tld 
mv  $DOSIS_DUMP_FILE  $filename 
if  (  -e  $filename  1=  1  )  then 

echo  "Failed  to  copy  transaction  log  dump  —  please  correct  and  rerun" 
exit(l) 
endif 
# 

#  report  success 

# 

echo  "DOSIS  transaction  log  dumped  to  $filename" 
exit(O) 


LOAD  ARCHIVED  DATA  FUNCTION  SCRIPTING 

#!csh 

# 

#  dosisjoad  [  DEV  ]  -  load  archive  from  /dev/DEV  (if  specified), 
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#  else  from  /dev/SDOSIS^TAPE 

# 

unset  noclobber 
# 

#  make  sure  all  required  environment  variables  are  set  correctly 

# 

if  (  $?DOSIS_COMMAND_DIR  =  0  )  then 
echo  "Environment  variable  DOSIS_COMMAND_DIR  not  set;  please  set  and  rerun" 
set  IX)SIS_COMMAND_DIR  =  dummy 
exit(l) 

else  if  (  -d  $DOSIS_COMMAND^DIR  =  0  )  then 
echo  "Environment  variable  DOSIS_COMMAND„DIR  does  not  designate  a  directory" 
echo  "  Please  set  and  rerun" 
exit(l) 
endif 

if  ( -e  $DOSlS_COMMAND^DIR/check_vars  ==  0  )  then 
echo  "$DOSIS_COMMAND_DIR/check_vars  script  does  not  exist" 
echo  "  Please  fix  and  rerun" 
exit(l) 
endif 

source  $DOSIS_COMMAND_DIR/check_vars 
if  (  Sstatus  !=  0  )  exit(l) 

# 

#  use  argument  for  tape  device  if  specified,  else  $DOSIS_TAPE 

# 

if  (  ^argv  ==  0  )  then 
if  (  $?DOSIS^TAPE  ==  0  )  then 

echo  "You  must  specify  a  tape  drive,  or  set  DOSIS_TAPE  environment  var." 
echo  "  Please  correct  and  rerun" 
exit(l) 
endif 

set  =  /dev/$DOSIS_TAPE 
else 

set  Tape  =  /dev/$argv[l] 
endif 
# 

#  make  sure  Tape  device  is  valid 

# 

if  ( -e  $T^  ==  0  )  then 

echo  "Tape  device  $Tape  does  not  exist.  Please  check  and  rerun" 
cxit(l) 
endif 
# 

#  load  the  archived  files  onto  disk 

# 

(  cd  $DOSIS_ARCHIVE  ;  tar  xvf  $Tape  >&DOSIStemp  ) 
if  (  $status  !=  0  )  then 

echo  "Cannot  read  archive  tape;  please  correct  below  errors  and  rerun" 
cat  DOSIStemp 
exit(l) 
endif 
# 

#  get  the  file  names;  make  sure  we  have  the  right  number 

# 

set  filenames  =  ‘awk  V'^x/  {  print  substr($2,l,14)  }’  DOSIStemp* 
if  (  3  *  $#filenames  !=  $#ArchiveTables  )  then 
echo  "Wrong  number  of  files  read  from  tape  -  please  correct  and  rerun" 
forcach  file  (  $filenames  ) 
tm  $DOSlS^ARCHIVE/$file 
end 
exit(l) 
endif 
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# 

#  get  the  date  from  the  file  names 

# 

set  Date  =  ‘awk  {  print  substr($2,l,8)  }*  DOSIStemp* 
while  (  $#Date  >  1  ) 
if  (  $Date[l]  !=  $Date[2]  )  then 

echo  "Files  read  from  tape  have  different  dates.  Please  correct  and  rerun" 
foreach  file  (  Sfilenames  ) 
im  $DOSIS_ARCHIVE/$file 
end 
exit(l) 
endif 
shift  Date 
end 
# 

#  verify  that  all  required  files  have  been  read  in 

# 

set  WorkArchiveTables  =  (  $ArchiveTables  ) 
unset  missing 

while  (  $#WorkArcliiveTables  !=  0  ) 
set  filename  =  $Date$ WorkArchiveTables [2]. ad 
set  return  :=  ‘grep  $filename  DOSIStemp* 
if  (  $#retum  =  0  )  then 
echo  "File  $filename  missing  from  tape" 
set  missing  =  1 
endif 

shift  WorkArchiveTables 
shift  WorkArchiveTables 
shift  WorkArchiveTables  . 
end 

if  (  $?missing  )  then 

echo  "Please  correct  above  errors  and  rerun" 
foreach  file  (  $filenames  ) 
nil  $DOSIS_ARCHlVE/$file 
end 
exit(l) 
endif 
# 

#  dump  the  transaction  log  before  starting  the  load  (since  it 
involves  bcp) 

# 

if  (  -e  $DOSIS_COMMAND_DIR/dosis_dumptran  ==  0  !1  \ 

-e  $DOSIS_COMMAND_DIR/dosis_dumpdb  ==  0  )  then 
echo  "Can’t  find  $DOSIS_COMMAND_DIR/dosis_dumptran  and/or  dosis_dumpdb  scripts" 
echo  "  Please  fix  and  reran" 
foreach  file  (  $filenames  ) 
rm  $DOSIS^ARCHIVE/$file 
end 
exit(l) 
endif 

sou rce  $DOSIS_COMMA ND__DIR/dosis_dumptran 
if  (  $$tatus  !=  0  )  then 
foreach  file  (  $filenames  ) 
mi  $DOSlS_ARCHIVE/$file 
end 
exit(l) 
endif 
# 

#  set  options  to  allow  us  to  bulk  copy  in 

# 

isql  -Usa  -PSSA^PASSWORD  «EXIT  >DOSlStemp 
sp_dboption  DOSIS,  selec,  true 
go 
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sp_dboption  DOSIS,  tninc,  true 

go 

use  DOSIS 
go 

checkpoint 

go 

EXIT 

diff  DOSISlemp  -  >/dev/null  «EXIT 

Run  the  CHECKPOINT  command  in  the  database  that  was  changed. 

(return  status  =  0) 

Run  the  CHECKPOINT  command  in  the  database  that  was  changed. 

(return  status  =  0) 

EXIT 

if  (  $status  !=  0  )  then 

echo  "Un^le  to  set  database  options:  please  correct  below  errors  and  rerun" 
cat  DOSIStemp 
foreach  file  (  $filenames  ) 
iTO  $DOSIS_ARCHIVE/$fde 
end 

csh  $DOSIS_COMMAND_DIR/dosis_dumpdb 
exit(l) 
endif 
# 

#  create  a  dummy  table  to  hold  the  LOAD_TABLE 

# 

isql  -Usa  -P$SA_PASSWORD  «EXIT  >DOSIStenip 
use  DOSIS 
go 

if  exists  (  select  *  from  sysobjects  where  name  =  "ArchiveTemp"  ) 
drop  table  ArchiveTemp 
go 

select  * 

into  ArchiveTemp 
from  LOADJTABLE 

where  CONTRACT_ID  =  ’This  will  match  no  IDs* 
go 

EXIT 

diff  DOSIStemp  -  >/dev/null  «EXIT 
(0  rows  affected) 

EXIT 

if  (  $status  !=  0  )  then 

echo  "Unable  to  create  LOAD_TABLE  temporary  table  for  analysis" 
echo  "  Please  correct  below  errors  and  rerun" 
cat  DOSIStemp 
foreach  file  (  $filenames  ) 
rm  $DOSIS^ARCHIVE/$file 
end 

csh  $DOSIS_COMMAND_DIR/dosis_dumpdb 
exit(l) 
endif 
# 

#  bulk  copy  in  the  load  table 

# 

bep  DOSIS.dbo.ArchiveTcmp  in  $DOSIS_ARCHlVE/${Date}LDT.ad  -n  -Usa\ 
-P$SA_PASSWORD  >DOSIStemp 
set  return  =  ‘grep  Msg  DOSIStemp* 
set  return  1  =  *grep  "rows  copied"  DOSIStemp* 
if  (  $#retuml  =  0  )  set  retuml  =(00) 
if  (  $#retum  !=  0  (I  $retuml[l]  ==  0  )  then 
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echo  "Bulk  copy  in  of  LOADJTABLE  failed  or  zero  rows  read" 
echo  "  Please  correct  below  errors  and  rerun" 
cat  DOSIStemp 
foreach  file  (  $filenames  ) 
iTO  $DOSIS^ARCHIVE/$rde 
end 

csh  $IX)SIS_COMMAND_DIR/dosis_dumpdb 
exit(l) 
endif 
# 

#  make  sure  we  are  not  duplicating  data 

# 

isql  -Usa  -P$SA_PASSWORD  «EXIT  >IX)SIStemp 
use  DOSIS 

go 

delete  ArchiveTemp 
where  LOADING  < 

(  select  max(LOAD_NO) 
from  ArchiveTemp ) 
go 

select  "marker",  count(*) 

from  ArchiveTemp  a,  LOAD_TABLE  1 

where  a^CONTRACTJD  =  1.CONTRACTJD 

and  a.PROJECT  =  1.PROJECT 

and  a.DREDGE  =  l.DREDGE 

and  aXOAD^NO  =  l.LOAD^NO 

go 

EXIT 

set  return  =  ‘grep  marker  DOSIStemp* 
set  return  1  =  ‘grep  Msg  DOSIStemp* 
if  (  $#retum  =  0  II  $#retuml  1=  0  )  then 
echo  "Check  for  duplicate  data  being  loaded  from  archive  failed" 
echo  "  Please  correct  below  errors  and  rerun" 
cat  DOSIStemp 
foreach  file  (  $filenames  ) 
rni  $DOSlS^ARCHIVE/$fde 
end 

csh  $DOSIS„COMMAND^DIR/dosis„dumpdb 
exit(l) 
endif 

if  (  $retum[2]  !=  0  )  then 

echo  "Duplicate  data  being  inserted  by  load  -  please  correct  and  rerun" 
foreach  file  (  Sfilenames  ) 
im  $DOSIS_ARCHIVEy$file 
end 

csh  $DOSIS_COMMAND_DIR/dosis_dunipdb 
exit(l) 
endif 
# 

#  now  bulk  copy  the  data 

# 

set  WorkArchiveTables  =  (  SArchiveTables  ) 
while  (  $#WorkArchiveTables  !=  0  ) 
bcp  DOSIS.dbo.$WorkArchiveTables[l]  in  \ 
$DOSIS^ARCHlVE/$Date$WorkArchiveTabIes[2].ad  -n  -Usa  -P$SA_PASSWORD  \ 
>DOSIStemp 

set  return  =  *grep  "Msgifail"  DOSIStemp* 
set  retuml  =  *grep  "rows  copied"  DOSIStemp* 
if  (  $#retum  !=  0  II  $#retuml  =  0  )  then 

echo  "****♦  BULK  COPY  IN  FAILED  FOR  LOADING  AN  ARCHIVE  *♦***" 
echo  "**♦*♦  YOUR  DOSIS  DATABASE  MAY  NOW  BE  INCONSISTENT  *****' 
echo  "♦****  WE  STRONGLY  RECOMMEND  RUNNING  dosis_restore  NOW  ****♦" 
echo  ’’♦****  see  below  errors  ♦*♦**•* 
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cat  DOSIStemp 
foreach  file  (  Sfilenames  ) 
im  $DOSIS>RCHIVE/$file 
end 
exil(l) 
endif 

shift  WorkArchiveTables 
shift  WoikArchiveTables 
shift  WoikArchiveTables 
end 
# 

#  Done  -  report  success,  dump  the  database 

# 

echo  "Archive  files  for  $Date  have  been  loaded" 
foreach  file  (  $filenames  ) 
im  $DOSIS_ARCHIVEy$file 
end 

csh  $DOSIS_COMMAND_DIR/dosis_dumpdb 
exit(O) 


RESTORE  DOSIS  DATABASE  FUNCTION  SCRIPTING 

#!csh 

# 

#  dosis_restore  -  restore  latest  DOSIS  database  and  transaction  log  dumps 

# 

unset  noclobber 

# 

#  make  sure  all  required  environment  variables  are  set  correctly 

# 

if  (  $?DOSIS_COMMAND^DIR  ==  0  )  then 
echo  "Environment  variable  DOSIS_COMMAND_DIR  not  set;  please  set  and  rerun" 
set  DOSIS^COMMAND^DIR  =  dummy 
exit(l) 

else  if  (  -d  $DOSIS^COMMAND_DIR  ==  0  )  then 
echo  "Environment  variable  DOSIS_COMMAND_DIR  does  not  designate  a  directory" 
echo  "  Please  set  and  rerun" 
exit(l) 
endif 

if  (  -e  $DOSIS_COMMAND_DIR/check^vars  ==  0  )  then 
echo  "$DOSIS_COMMAND_DIR/check_vars  script  does  not  exist" 
echo  "  Please  fix  and  rerun" 
exit(l) 
endif 

source  $DOSIS_COMMAND_DIR/chcck_vars 
if  (  $status  !=  0  )  exit(l) 

# 

#  find  latest  database  dump 

# 

set  DatabaseDumps  =  (  $DOSIS_COMMAND^DIR/check*_vars  $DOSIS_BACKUP/*.dbd  ) 
shift  DatabaseDumps 
if  (  $#DatabaseDumps  =  0  )  then 
echo  "No  IX)SIS  database  dumps  available;  cannot  restore!" 
exit(l) 
endif 

while  (  $#Database Dumps  >  1  ) 
shift  DatabaseDumps 
end 
# 

#  load  database  dump 
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# 

q)  SDatabaseDumps  $DOSlS_DUMP_FILE 
if  (  $status  !=  0  )  then 

echo  "Copy  of  database  dump  $DatabaseDumps  failed" 
echo  "  Please  correct  and  rerun" 
exit(l) 
endif 

isql  -Usa  -P$SA_PASSWORD  «EXIT  >DOSIStemp 
load  database  DOSIS  from  $DOSIS_DUMP_DEVICE 
go 

EXIT 

set  return  =  ‘cat  DOSIStemp* 
if  (  $#retum  !=  0  )  then 

echo  "Load  of  database  dump  SDatabaseDumps  failed" 
echo  "  Please  correct  below  errors  and  rerun" 
cat  DOSIStemp 
exit(l) 
endif 

echo  "DOSIS  database  dump  loaded  from  SDatabaseDumps" 

# 

#  load  transaction  dumps 

# 

set  LogDumps  =  (  $DOSIS_COMMAND_DIR/check*^vars  $DOSIS_BACKUP/*.tld  ) 
shift  LogDumps 
while  (  $#LogDump$  >  0  ) 
sort  «EXIT  >DOSIStemp 
$LogDumps[l]:r 
SDatabaseDumps :  r 
EXIT 

set  return  =  ‘cat  DOSIStemp* 

if  (  Sretum[l]  =  SDatabaseDumps :r  &&  Sretum[2]  !=  SDatabaseDumps:r  )  then 
cp  SLogDumps[l]  SDOSIS^DUMP.RLE 
if  (  Sstatus  1=  0  )  then 

echo  "Copy  of  transaction  log  dump  $LogDumps[l]  failed" 
echo  "  Please  correct  and  rerun" 
exit(l) 
endif 

isql  -Usa  -PSSA_PASSWORD  «EXIT  >DOSIStemp 
load  transaction  DOSIS  from  $D0S1S_DUMP_DEVICE 
go 

EXIT 

set  return  =  ‘grep  msg  DOSIStemp* 
if  (  S#retum  !=  0  )  then 

echo  "Load  of  transaction  log  SLogDumpsfl]  failed" 
echo  "  Please  correct  below  errors  and  rerun" 
cat  DOSIStemp 
exit(l) 
endif 

echo  "DOSIS  transaction  log  loaded  from  SLogDumps[l]" 
endif 

shift  LogDumps 
end 
# 

#  success  message 

# 

echo  "DOSIS  restore  complete" 
exit(0) 
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COPY  ARCfflVED  FILES  FUNCTION  SCRIPTING 

#!csh 

# 

#  dosis_tape  [  yyyymmdd  ]  [  DEV  ] 

#  copy  ardlive  files  for  yyyymmdd  (if  specified),  else  oldest  files 

#  to  /dev/DEV  (if  specified),  else  to  /dev/$DOSIS_TAPE 

# 

unset  noclobber 
# 

#  make  sure  all  required  environment  variables  are  set  correctly 

# 

if  (  $?DOSIS^COMMAND_DIR  ==  0  )  then 
echo  "Environment  variable  DOSIS_COMMAND_DIR  not  set;  please  set  and  rerun" 
set  DOSIS_COMMAND_DIR  =  dummy 
exit(l) 

else  if  ( -d  $DOSIS^COMMAND_DIR  =  0  )  then 
echo  "Environment  variable  IX)SIS_COMMAND_DIR  does  not  designate  a  directoiy" 
echo  ”  Please  set  and  rerun" 
exit(l) 
endif 

if  ( -e  $DOSlS_COMMAND„DIR/check„vars  ==  0  )  then 
echo  ”$DOSIS_COMMAND_DIR/check_vars  script  does  not  exist" 
echo  ”  Please  fix  and  rerun" 
exit(l) 
endif 

source  $IX)SIS_COMMAND_DIR/check_vars 
if  (  $status  !=  0  )  exit(l) 

# 

#  check  on  how  many  arguments  we  have;  set  Date  and  Tape  as  appropriate 

# 

unset  Date 
unset  Tape 
switch  (  $#argv  ) 
case  0: 

breaksw 
case  1: 

egrep  ’markerl91marker20*  «EXIT  >DOSIStemp 
marker$argv[l] 

EXIT 

set  return  =  ‘cat  DOSIStemp* 
if  (  $#retum  =  1  )  then 
set  Date  =  $argv[l] 
else 

set  Tape  =  $argv[l] 
endif 
breaksw 
case  2: 
default: 

set  Date  =  $argv[l] 
set  Tape  =  $argv[2] 
breaksw 
endsw 
# 

#  fmd  oldest  archived  files  if  date  is  not  specified 

# 

if  (  $?Date  ==  0  )  tlien 

set  Date  =  (  $DOSlS^COMMAND.DIR/check*_vars  $DOSIS_ARCHIVE/*.ad  ) 
shift  Date 

if  (  $#Date  ==  0  )  then 

echo  "No  archive  files  are  present.  Please  take  an  archive  and  rerun" 
exit(l) 
endif 
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awk  ’{  print  substK$14tS)  }’  «EXIT  >DOSIStemp 
$Date[l]:t 
EXIT 

set  Dale  =  ‘cat  DOSIStemp* 
endif 
# 

#  set  Tape  if  tape  has  not  been  specified 

# 

if  (  $?Tape  =  0  )  then 
if  (  $?DOSIS^TAPE  =  0  )  then 

echo  "You  must  specify  a  tape  drive,  or  set  DOSISJTAPE  environment  van" 
echo  "  Please  correct  and  rerun" 
exit(l) 
endif 

set  Tape  =  $DOSIS_TAPE 
endif 

set  Tape  =  /dev/$Tape 
# 

#  make  sure  Tape  device  is  valid 

# 

if  ( -e  $Tape  =  0  )  then 

echo  "Tape  device  $Tape  does  not  exist.  Please  check  and  rerun" 
exit(l) 
endif 
# 

#  make  sure  all  archive  files  exist 

# 

set  WorkArchiveTables  =  (  $ArchiveTables  ) 
unset  error 

while  (  $#WorkArchiveTables  !=  0  ) 
set  filename  =  $DOSlS_ARCHIVE/$Date$WorkArchiveTables[2].ad 
if  (  -e  $filename  ==  0  )  then 

echo  "Archive  file  Sfilename  does  not  exist.  Please  correct  and  rerun" 
set  error  =  1 
endif 

shift  WorkArchiveTables 
shift  WorkArchiveTables 
shift  WorkArchiveTables 
end 

if  (  $?eiTor  )  then 

echo  "Please  correct  above  errors  and  rerun" 
exit(l) 
endif 
# 

#  make  the  tape 

# 

(  cd  $DOSIS_ARCHIVE  ;  tar  cf  $Tape  $Date*.ad  ) 
if  (  $status  !=  0  )  then 

echo  "Creation  of  archive  tape  failed:  Please  correct  above  errors  and  rerun" 
exit(l) 
endif 

echo  "$Date  archive  written  to  $Tape" 
exit(0) 
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Appendix  C 

Configuration  Management 
Library  Structure 


The  format  of  the  file  listings  within  the  Configuration  Management  Li¬ 
brary  Structure  is  as  follows: 

/directory-name/directory-name/.../file-name 

The  files  contained  within  the  Silent  Inspector  system  are: 

/BINDING/vadscitl.O 

/SAME/standardS.a 

/BINDING/libasybdb.a 

/SAME/systemS.a 

/BINDING/libsybdb.a 

/SAME/booleanB.a 

/BINDINGA^_usr__conf .  a 

/SL-MODELS/s.proj_add.g 

/BINDINGA^_usr_conf_b.a 

/SL-MODELS/p.Makefile 

/BINDINGA^_usr_confJ.a 

/SL-MODELS/s.Makefde 

/BINDING/c_timeB.o 

/SL-MODELS/s.mk_butlon.g 

/BINDING/xev.o 

/SL-MODELS/s.mfiledblg 

/SAME/basetypeS.a 

/SL-MODELS/s.fldent_sz.g 

/SAME/booleanS.a 

/SL-MODELS/Makefile 

/SAME/charB.a 

/SL‘MODELS/s  .m_retum.g 

/SAME/charS.a 

/SL-MODELS/s.fldent85.g 

/S  AME/commun  icB .  a 

/SL-MODELS/s.m_calll  .g 

/S  AME/commtmicS  .a 

/S  L- MO  D  ELS/s  .t  i  met  rend.g 

/SAME/db__errorB  .a 

/SL-MODELS/CorpLogo.m  1 

/SAME/dateS.a 

/SL-MODELS/s.N^call.g 

/SAME/db_errorS.a 

/SL-MODELS/s.da_twobut.g 

/SAME/doubleB.a 

/SL-MODELS/s.m_l_column.g 

/SAME/doubleS.a 

/SL-MODELS/M_caU.m  1 

/SAME/enumB.a 

/SL-MODELS/M_default.m  1 

/SAME/enumS.a 

/SL-MODELS/s.m_quit.g 

/SAME/intB.a 

/SL-MODELS/s.daily.g 

/SAME/exceptS.a 

/SL-MODELS/s.day_foot.g 

/SAME/intS.a 

/SL-MODELS/s.day_head.g 

/SAME/realB.a 

/SL-MODELS/s.day_lme.g 

/SAME/realS.a 

/SL-MODELS/s.day_total.g 

/SAMEAo_strinX.a 

/SL-MODELS/s.day_totft.g 

/SAME/smallintB.a 

/SL-MODELS/s.day_tothd.g 

/SAME/smallintS.a 

/SL-MODELS/s.m^calLg 

/SAME/not_nullX.a 

/SL-MODELS/N_caU.ml 

/SAME/sourceS.a 

/SL-MODELS/Infomiatio.m  1 
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/SL-MODELS/Waming.ml 

/SL-MODELS/s.floatout.g 

/SL- MODELS  Ajack  ground.m  1 

/SL-MODELS/backdrop.m  1 

/SL-MODELS/butlon.m  1 

/SL-MODELS/choice.m  1 

/SL-MODELS/controLm  1 

/SL-MODELS/da  Jwobut.m  1 

/SL-MODELS/s.legend.g 

/SL-MODELS/daily.ml 

/SL'MODELS/s.mo^pushbut.g 

/SL-MODELS/s.m_dialog,g 

/SL-MODELS/s.m_diiarrow,g 

/SL-MODELS/s.m_slidehx.g 

/SL-MODELS/s.m_slider.g 

/SL-MODELS/day__foot.m  1 

/SL-MODELS/s.m^sUdehxl.g 

/SL-MODELS/s.m_slidevxl.g 

/SL''MODELS/s.m_txlscrol,g 

/SL-MODELS/s.m_upaiTow.g 

/SL-MODELS/s.mfilesel.g 

/SL-MODELS/s.md_button2.g 

/SL-MODELS/s  .pushface.g 

/SL-MODELS/day_head.m  1 

/SL-MODELS/s.plot.g 

/SL-MODELS/s.panel.g 

/SL-MODELS/dayJine.ml 

/SL-MODELS/day^total.m  1 

/SL-MODELS/day_totft.ml 

/SL-MODELS/day_tothd.m  1 

/SL-MODELS/do_lwobut.m  1 

/SL-MODELS/downtime.m  1 

/SL-MODELS/s. stanip.g 

/SL-MODELS/s.plt_twobut.g 

/SL-MODELS/s.scrollst.g 

/SL-MODELS/s.CorpLogo.g 

/SL-MODELS/s.Infomialio.g 

/SL-MODELS/s,M^caU.g 

/SL-MODELS/s.M_default.g 

/SL-MODELS/s.Waming.g 

/SL-MODELS/s.background.g 

/SL-MODELS/s.quitbutton.g 

/SL-MODELS/s.button.g 

/SL-MODELS/s,choice.g 

/SL-MODE  LS/s  .control  .g 

/SL-MODELS/s  .repoitbar.g 

/SL-MODELS/s.  reportpg.g 

/SL-MODELS/s.reportst.g 

/SL-MODELS/dr_ops.ml 

/SL-MODELS/s.scrollbox.g 

/SL-MODELS/draftx.ml 

/SL-MODELS/s  .text_sz.g 

/SL-MODELS/s.text_fz.g 

/SL-MODELS/s.lext_left.g 

/SL-MODELS/s.textout.g 

/SL-MODE  LS/s  .do_twobut.g 

/SL-MODE  LS/s  .downtime,  g 

/SL-MODELS/s.dr_ops,g 

/SL-MODELS/s.draftx,g 

/SL-MODELS/s.ds_pushbut.g 

/SL-MODELS/s.dss.g 

/SL-MODE  LS/s. dssentry.g 


/SL-MODELS/s. dssscreen.g 

/SL-MODELS/s.dt_input.g 

/SL-MODELS/s.entry.g 

/SL-MODELS/ds_pushbut.m  1 

/SL-MODELS/s.gen^head.g 

/SL-MODELS/s.intro.g 

/SL-MODELS/s.job.g 

/SL-MODELS/s  .job_head.g 

/SL-MODELS/dss.ml 

/SL-MODELS/s.top.g 

/SL-MODELS/s.text_box  .g 

/SL-MODELS/dssentry.ml 

/SL-MODELS/dssscreen.m  1 

/SL-MODELS/dt  Jnputm  1 

/SL-MODELS/enlry.ml 

/SL-MODELS/fldent85.ml 

/SL-MODELS/floatout.m  1 

/SL-MODELS/intro.ml 

/SL-MODELSAegend.ml 

/SL-MODELS/s.md_button  .g 

/SL-MODELS/m_l  ^column  .m  1 

/SL-MODELS/m_caU.ml 

/SL-MODELS/m^calll.ml 

/SL-MODELS/s  .motifscale.g 

/SL-MODELS/s.noptions.g 

/SL-MODELS/s.options.g 

/SL-MODELS/s.outputdbl.g 

/SL-MODELS/s.outputonly.g 

/SL-MODELS/s. outputwide.g 

/SL-MODELS/m_dialog.ml 

/SL-MODELS/m_dnarrow.m  1 

/SL-MODELS/s.trip_line.g 

/SL-MODELS/s.print.g 

/SL-MODELS/s.pushbutton.g 

/SL-MODELS/s  .trip__total.g 

/SL-MODELS/m„quit.ml 

/SL-MODELS/ni_retum.m  1 

/SL-MODELS/m_slideh.ml 

/SL-MODELS/m_slidehx.m  1 

/SL-MODELS/m_slidehxl.m  1 

/SL-MODELS/m_slider.ml 

/SL-MODELS/s.select4.g 

/SL-MODELS/m^slidevxl.m  1 

/SL-MODELS/m_txtscrol.m  1 

/SL-MODE  LS/m_upaiTOw.m  1 

/SL-MODELS/md_button2.m  1 

/SL-MODELS/md_button.m  1 

/SL-MODELS/mfilesel.ml 

/SL-MODELS/mk_button.m  1 

/SL- MODELS/nio__pushbut  .m  1 

/SL-MODELS/s.trip.g 

/SL-MODE  LS/s  .trip_foot.g 

/SL-MODELS/s.trip_head.g 

/SL-MODELS/motifscale.ml 

/SL-MODE  LS/navaid.m  1 

/SL-MODELS/noptions.m  1 

/SL-MODELS/opti  ons.m  1 

/SL-MODELS/outputdbl.m  1 

/SL-MODELS/outputonly.m  1 

/SL-MODELS/outputwide.ml 

/SL-MODELS/panel.ml 

/SL-MODELS/plot.ml 
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/SL-MODELS/plt_twobut.m  1 

/S  YB  ASEAlinesAtwo_phbO  1 

/SL-MODELS/^itland.m  1 

/SYBASEAnets/INSTBXX 

/SL-MODELS/print.ml 

/SYBASEAnets/INSTHXX 

/SL-MODELS/pu  shbutton.m  1 

/SYBASE/.netsAVerdixsOl 

/SL-MODELS/pushface.ml 

/SYBASEAnetsAVerdixs02 

/SL-MODELS/qu  itbutton  .m  1 

/SYBASEAnetsAbaraOl 

/SL“MODELS/reportbar,m  1 

/SYBASEAnetsAbara02 

/SL-MODELS/rcportpg.m  1 

/SYBASEAnetsAbcpJowsOl 

/SL-MODELS/reportst.m  1 

/SYBASEAnetsAbcpJows02 

/SL-MODELS/s.m^slideh.g 

/SYBASEAnetsAbcpbOl 

/SL-MODELS/s.backdrop.g 

/SYBASE/.netsAbcpsOl 

/SL-MODELS/scroUbox.m  1 

/SYBASE/.netsAc_eiT_hds01 

/SL-MODELS/scroUst.ml 

/SYB  AS  EAnetsAc_err_hds02 

/SL-MODELS/showmap.m  1 

/SYBASEAnetsAc_msg_hds01 

/SL-MODELS/s.navaid.g 

/SYBASEAnetsAc_msg_hds02 

/SL-MODELS/s.portland.g 

/SYBASEAnetsAeiT_hd_ctrb01 

/SL-MODELS/stamp,m  1 

/SYBASEAnetsAeiT_hd_ctrs01 

/SL-MODELS/c.awk 

/S  YB  ASEAnets/.err^hdbO  1 

/SL-MODELSAext_box.m  1 

/SYBASEAnetsAerr_hds01 

/SL-MODELS/textJz.ml 

/SYBASEAnetsAexample2pca01 

/SL-MODELS/textJeft.m  1 

/SYBASEAnets/.handlersbOl 

/SL- MODELS  Aext_sz.m  1 

/SYBASEAnets/.handlerssOl 

/SL-MODELS/textout.m  1 

/SYBASE/.netsAifaceJowsOi 

/SL-MODELSAimetrend.m  1 

/SYBASE/.netsAifaceJows02 

/SL-MODELSAop.ml 

/SYBASE/.nets/.ifacebOl 

/SL-MODELSArip.ml 

/SYBASE/.nets/.ifacesOl 

/SL-MODELS/s.showmap.g 

/S  YB  ASEAnetsAmsg_hd_ctrbO  1 

/SL-MODELS/s,value.g 

/SYBASEAnetsAnisg_hd_ctrs01 

/SL-MODELSArip_foot.m  1 

/SYBASEAnetsAnisg_hdb01 

/SL-MODELSArip_head.m  1 

/SYBASEAnetsAmsg_hds01 

/SL-MODELSArip^line,m  1 

/SYBASEAnetsAproc_evntsb01 

/SL-MODELSArip_total.m  1 

/SYBASE/.nets/.proc^evntssOl 

/SL-MODELSMlue.m  1 

/SYBASEAnets/.scounixsOl 

/SL-MODELS/job.ml 

/SYBASEAnetsAscounixs02 

/SL-MODELS/job_head.m  1 

/SYBASEAnets/.str^utilbOl 

/SL-MODELS/select4.m  1 

/SYBASE/.nets/.strjutilsOl 

/SYBASE/.imports/STANDARD 

/S  YB  ASEAnetsAtwo_ph_lowsO  1 

/SYB  AS  E/.  imports/a_st  rings 

/SYBASEAnetsAtwo_ph_lows02 

/SYBASE/.imports/file_suppoit 

/S  YBASEAnetsAtwo__phbO  1 

/SYBASE/.iniports/io_exceptions 

/SYBASE/.netsAtwo__phsO  1 

/SYBASE/.imports/number_io 

/SYBASE/.netsAlypessOl 

/SYBASE/,imports/os_files 

/SYBASEAnetsAtypess02 

/SYBASE/.imports/system 

/SYBASEAobjects/INST13XX 

/SYBASE/.importsAextJo 

/SYBASEAobjects/INST14XX 

/SYBASE/.importsAextJo.intege 

/S  YB  ASE/.objects/example  1.0 

/SYBASE/.importsAext_ioB 

/SYBASEAobjects/example2.o 

/SYBASE/.importsAext_supprt 

/SYBASEAobjects/example3.o 

/SYBASE/.importsAext_supprtB 

/SYBASE/.objects/example4.o 

/S  YB  AS  E/.  iniports/unchecked__conv 

/SYBASE/.objects/exampleS.o 

/SYBASE/.imports/unsigned_types 

/SYBASE/.objects/example6.o 

/S  YB  ASEAlines/INSTl  3XX 

/SYBASE/.objects/exampleV.o 

/SYBASE/.Unes/INST14XX 

/S  YB  AS  E/.obj  ecls/example8.o 

/SYBASE/.lines/.bara02 

/S  YB  AS  E/.obj  ectsA  VerdixsO  1 

/SYBASEAlines/.bcpbOl 

/SYBASEAobjectsAVerdixs02 

/SYBASEAlinesAeiT_hd_ctrb01 

/SYBASE/.objects/.baraOl 

/SYBASEAlinesAerr_hd_ctrs01 

/SYB  AS  E/.obj  ectsAbara02 

/SYBASEAlinesAexample2pca01 

/S  YB  AS  E/.obj  ects/.bqjJowsOl 

/S  YB  ASEAlinesAhandlersbO  1 

/SYBASEAobjectsAbq)_lows02 

/SYBASEAlinesAifacebOl 

/SYBASEAobjecis/.bqjbOl 

/SYBASEAlinesAmsg_hd_ctrb01 

/SYBASE/.objects/.bqjsOl 

/S  YB  ASEAlinesAmsg_hd_clrsO  1 

/SYBASE/.objects/.c_err_hds01 

/SYBASEAlinesAproc^evntsbOl 

/SYBASEAobjects/.c_eiT_hds02 

/SYBASE/.linesAstr_utilb01 

/SYBASE/.objects/.c_msg_hds01 
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/SYBASE/.objecU/.c_msg_hds02 

/S  YB  ASE/.objecls/.eiT_hd_ctrbO  1 

/SYBASE/.objects/.err_hd_ctrs01 

/SYBASEAobjects/.example2pca01 

/SYBASE/.objectsAhandlersbOl 

/SYBASEAobjectsAhandlerssOl 

/SYBASEAobjectsAiface_lows01 

/SYBASEAobjeclsAiface_lows02 

/S  YB  ASEAobjects/.ifacebO  1 

/SYBASE/.objectsAifacesOl 

/S  YB  ASEAobjectsAnisg_hd_ctrbO  1 

/S  YB  ASE/.objects/.insg_hd_ctrsO  1 

/SYB  ASE/.objects/.proc_evnlsbO  1 

/SYB  ASEAobjectsAproc_evntssO  1 

/SYBASEAobjectsAscounixsOl 

/SYBASEAobjectsAscounixs02 

/S  YB  ASEAobjectsAstr_utilbO  1 

/SYBASEAobjects/.str_utils01 

/SYBASEAobjectsAtwo_phJows01 

/SYBASEAobjectsAlwo_ph_lows02 

/SYBASEAobjectsAtwo_phb01 

/SYBASEAobjectsAtwo_phs01 

/S  YB  ASEAobjects/.typessO  1 

/S  YB  ASEAobj  ects/.typess02 

/database/Mak  ef  ile 

/database/adm_conS.a 

/database/adminS.a 

/database/db_stdS.a 

/database/disp__conS.a 

/database/di  sposalS .  a 

/database/down_conS.a 

/database/downtimeS.a 

/ database/dr_con  S.a 

/database/dredgeS.a 

/database/enumJndS.a 

/database/flt_indS  .a 

/database/gsqlutlS.a 

/database/gsybutlS.a 

/database/intJndS,a 

/database/lddisconS.a 

/database/ldstaconS.a 

/databaseAoadS.  a 

/database/load_conS.a 

/databaseAoaddispS.a 

/databaseAoadstatS.a 

/database/prdisconS.a 

/database/proj_conS.a 

/database/projdispS.  a 

/database/projd  redS .  a 

/database/projectS.a 

/database/projstatS.a 

/database/proj  suniS.  a 

/database/prstaconS.a 

/database/prsumconS.a 

/database/sta_coiiS.a 

/database/stateS.a 

/database/stateconS.  a 

/database/$tatiofiS.a 

/databa$e/str_indS.a 

/databasc/syb_lowS.a 

/database/syb_utlS.a 

/database/sql_utlS.a 


/database/prdr_conS.a 

/database/adm_conB  .a 

/database/adminB.a 

/database/databaseB  .a 

/database/disp_conB.a 

/database/disposalB  .a 

/database/down_conB  .a 

/database/downtimeB.a 

/database/dr_conB,a 

/database/dredgeB .  a 

/database/cnumJndB.a 

/database/flt_mdB.a 

/database/gsqlutlB  .a 

/database/gsybutlB.a 

/database/int_i  nd  B .  a 

/database/lddisconB.a 

/databaseAdstaconB.a 

/databa  se/load  B .  a 

/database/load_conB.a 

/database/loaddispB.a 

/database/loadstatB.a 

/database/prdisconB  .a 

/databa  se/prd  r_con  B .  a 

/database/proj_conB.a 

/database/projd  ispB. a 

/databa  se/proj  d  redB  .a 

/dalabase/proJectB  .a 

/databa  se/projslatB.a 

/database/proj  s  umB .  a 

/database/prstaconB  .a 

/database/prsumconB.a 

/database/sql_utlB  .a 

/database/sta_coiiB  .a 

/database/stateB.a 

/database/stateconB.a 

/dalabase/slationB  .a 

/databa  se/st  r_ind  B .  a 

/database/syb_utlB.a 

/dss/RANGE.DAT 

/dss/Makefile 

/dss/CorpLogo.ni  1 

/dss/stanip.ml 

/dss/button.ml 

/dss/pushface.ml 

/dss/mfilesel.ml 

/dss/motifscale.ml 

/dss/dssenlry.m  1 

/dss/quitbutton.nil 

/ds  s/pan  el  .ml 

/dss/outputwide.m  1 

/dss/print.ml 

/dss/outputdbl.ml 

/dss/outpulonly.m  1 

/dss/background.ml 

/dss/ds_4)ushbut.m  1 

/dss/pu  shbutton  .m  1 

/dss/options.ml 

/dss/noptions.ml 

/dss/dssscreen.ml 

/dss/choice.ml 

/dss/intro.ml 

/dss/entry.m  1 


Appendix  C  Configuration  Management  Library  Structure 


/dss/dss.ml 

/ship/reportsAripAop.m  1 

/dss/control.ml 

/ship/reportsArip/repoitbar.m  1 

/dss/controlS.a 

/ship/reportsArip/reportpg,m  1 

/dss/entiyS.a 

/ship/reportsArip/repoitst.m  1 

/dss/gismosS.a 

/ship/reportsArip/scroUst.m  1 

/dss/input__fiS.a 

/ship/reportsAripAripS.a 

/dss/sensorS.a 

/ship/reportsAripAripA  .a 

/dss/sinitS.a 

/ship/rcporUArip/autolripA  .a 

/dss/dssA.a 

/ship/repoitsAripAripB.a 

/dss/sinitB.a 

/ship/repoitsArip/autotrip 

/dss/contix>lB.a 

/ship/reports/daily /Makefile 

/dss/entryB.a 

/ship/report3/daily/M_call.m  1 

/dss/gismosB.a 

/ship/repoits/daily/M_default.m  1 

/dss/input_riB.a 

/ship/reports/daily/N_caU.in  1 

/dss/sensorB.a 

/ship/reports/daily/W  aming.m  1 

/shipAnonitor/Makefde 

/ship/reports/daily/backgrcMind.m  1 

/ship/monitorAimetrend.m  1 

/ship/reports/daily/daily.m  1 

/ship/monitor/stamp.m  1 

/ship/repoits/daily/day_foot.m  1 

/ship/monitorAextout.m  1 

/ship/reports/daily/day_head.m  1 

/ship/monitorAext_sz,m  1 

/ship/reports/daily/day_line.m  1 

/shipAnonitor/pushface.m  1 

/ship/repoits/daily/day_total.m  1 

/ship/monitorAno^pushbutm  1 

/ship/reports/daily/day_totft.m  1 

/ship/monitor/paneLm  1 

/ship/reporls/daily/dayjothd.m  1 

/ship/monitor/Iegend.m  1 

/sh  1  p/reports/daily/m_  1  ^column  .m  1 

/ship/monitor/floatout.m  1 

/ship/reports/daily/m_call.m  1 

/ship/monitor/draftx.m  1 

/ship/reports/daily/m_dialog,m  1 

/ship/monitorAiackground.ml 

/ship/reports/daily/m_dnaiTow.m  1 

/shipAnoiiitor/dr_ops.m  1 

/ship/reports/daily/m_slidehx.m  1 

/ shi  p/monitor/d  r_opsS.  a 

/ship/reports/daily/m_slidehxl,m  1 

/ship/monitor/sinitS.a 

/ship/reports/daily/m_slider.m  1 

/ship/monitor/dr_opsB.a 

/ship/reports/daily/m_slidevxl.iiil 

/ship/monitor/sinitB.a 

/ship/reports/daily/m_txtscrol.m  1 

/ship/monitor/moiiitorA.a 

/ship/reports/daily/m_upaiTow.m  1 

/ship/repoitsAHp/Makefile 

/ship/reports/daily/mfilesel.m  1 

/ship/repoitsArip/lnfomiatio.m  1 

/ship/reports/daily/pushface.m  1 

/ship/reports  AripA>ackgFound.m  1 

/ship/reports/daily/quitbutton.ml 

/ship/reporuArip/m_dialog.m  1 

/sh  ip/repo  rts/daily/reportba  r.  m  1 

/ship/repoitsArip/pushfaoe.ml 

/ship/reports/daily/reportpg.m  1 

/ship/reportsAHp/quitbutton.m  1 

/ship/reports/daily/reportst.m  1 

/ship/reportsArip/mfilesel.m  1 

/ship/reports/daily/scroUbox.m  1 

/ship/rcpoitsArip/text_sz.m  1 

/ship/reports/daily/scrollst.m  1 

/ship/reportsArip/text_fz.m  1 

/ship/reports/daily/stanip.m  1 

/ship/reportsArip/text_left.m  1 

/ship/reports/daily  Aext_fz.m  1 

/ship/repoitsArip/stamp.m  1 

/ship/report  s/dailyAext__left.m  1 

/ship/repoitsAripArip.m  1 

/ship/reports/daily  Aext_sz.m  1 

/ship/rcpoitsAripArip_foot.m  1 

/ship/reports/dailyAop.m  1 

/ship/repoitsAripArip_head.m  1 

/ship/repo  rts/daily/da_twobut.m  1 

/ship/reportsAripArip^line.m  1 

/ship/reports/daily/dailyS.a 

/ship/reportsAripArip_total.m  1 

/sh  ip/repo  rts/daily/da  ily  A  .a 

/ship/reportsArip/M_call.m  1 

/ship/repo  rts/daily/autodalyA.a 

/ship/reporlsArip/M_defauIt.m  1 

/sh  ip/reports/daily/da  tly  B  .a 

/ship/reponsArip/N_call.ni  1 

/sh  ip/reports/job/Makefile 

/ship/reporlsArip/W  aming.m  1 

/ship/reports/job/job.m  1 

/ship/reportsArip/m_l_column.m  1 

/ship/reports/job/job_head.m  1 

/ship/repoitsArip/m_call.m  1 

/ship/reports/jobAnformatio.m  1 

/ship/reportsArip/m_dnarrow.m  1 

/ship/reports/job/background.m  1 

/ship/reportsArip/m_slidehx  .m  1 

/ship/reports/job/do_lwobut.m  1 

/ship/reportsArip/m_slidehxl.m  1 

/ship/reports/job/m_diaIog.m  1 

/ship/reportsArip/ni_slider.m  1 

/ship/reports/job/pusliface.m  1 

/ship/rcportsArip/m_slidevxl.m  1 

/ship/reports/job/quitbutton.m  1 

/ship/reportsArip/m_txt  scrol.m  1 

/ship/reports/job/mfdesel.m  1 

/ship/reportsArip/m_upaiTow.m  1 

/ship/reports/jobAext_sz.m  1 

/ship/rcpoitsArip/scrollbox.m  1 

/ship/reports/jobAext_fz.m  1 
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/ship/reports/jobAexl 1 
/ship/rcports/job/stamp.m  1 

/ship/plot/plotA.a 

/ship/reports/jcrf>/M_caU.m  1 

/ship/plot/plotB  .a 

/ship/reports/job/M_defaull.m  1 

/ship/rtkemelA.a 

/ship/reports/job/N_call.m  1 

/support/Makefile 

/ship/reports/job/W  aming.m  1 

/  support/cstrin  gsS .  a 

/ship/reports/job/m_l_coliimn.m  1 

/support/coorS.a 

/ship/reports/job/m_call.m  1 

/support/debugA  .a 

/ship/reports/job/m_(kiarrow.m  1 

/su  pport/di  alogstS  .a 

/ship/repoits/job/m_slidehx.m  1 

/support/domainS.a 

/ship/reports/job/m_slidehxl.m  1 

/support/ficldmgrS.a 

/ship/reports/job/m_slider.m  1 

/support/genericstS.a 

/ship/reports/job/m_slidevxl.m  1 

/support/getenvA  .a 

/ship/repoits/job/m_txtscrol.m  1 

/  support/graph  stS.  a 

/ship/repoits/job/m_iq)arrow,m  1 

/suppott/id_serverS.a 

/ship/reports/job/md_butlon.m  1 

/suppoit/mapS.a 

/ship/reports/job/scroUbox.m  1 

/support/menubarstS.a 

/$hip/reports/jobAop.m  1 

/support/random  S.a 

/ship/reports/job/repoitbar.m  1 

/support/reportstS.a 

/ship/reporls/job/reportpg.m  1 

/support/scrollstS.a 

/ship/reports/jdj/reportst.m  1 

/  su  ppo  rt/s  earchS.  a 

/ship/reporU/job/scroUst.m  1 

/support/supporlS.a 

/  ship/reports/job/jobS.  a 

/supportAe  mii  oS .  a 

/ship/reports/job/jobA.a 

/supportAimeS.a 

/ship/rcports/job/jobB.a 

/supportAo_sA.a 

/ship/downtime/Makefile 

/supportAo_vA.a 

/ship/downtimc/N„call.m  1 

/supportAodS.a 

/ship/downtime/background.m  1 

/support  A^ad  s  initS  .a 

/ship/do  wntime/downtime.  m  1 

/suppoit/databaseS.a 

/ship/downtune/dt_input.m  1 

/support/graphS.a 

/ship/do  wntime/m^call.m  1 

/support/rep_genS.a 

/ship/downtime/mdjbutton.m  1 

/support/dredgeioS.a 

/ship/downtiine/fldent85.m  1 

/support/computeS.a 

/ship/downtiine/mfdeseLm  1 

/support/computeB.a 

/ship/downtune/^shface.m  1 

/support/coorB.a 

/ship/downtime/stamp.m  1 

/support/cstringsB.a 

/ship/downtime/scrallst.m  1 

/support/cl27strS.a 

/ship/downtime/scrolibox.m  1 

/support/dialogslB  .a 

/ship/downt!me/m_txtscrol.m  1 

/support/dredgeioB.a 

/ship/downllnie/m_dnarrow.m  1 

/support/fieldmgrB.a 

/ship/downtime/m_uparrow.m  1 

/support/genericstB.a 

/ship/downtime/m_slider.m  1 

/support/graphB.a 

/ship/downtime/m_l_column.m  1 

/support/graphstB.a 

/ship/downtiine/mk_button.m  1 

/support/id_serverB  .a 

/ship/downtimeAext_fz.m  1 

/support/mapB.a 

/ship/downtiineAext_sz.m  1 

/support/menubarstB.a 

/ship/downtime/do_twobut.m  1 

/support/raiidomB  .a 

/ship/downtime/dfldprocS.a 

/support/rep_genB .  a 

/ship/downtime/dtinputS,a 

/support/reportstB  .a 

/ship/downtime/dtselectS.a 

/support/scrollstB .  a 

/ship/downlime/downtimeA.a 

/support/searchB.a 

/ship/downtime/dfldprocB.a 

/support/supportB.a 

/ship/downtime/dtinputB  .a 

/supportAimeB.a 

/ship/downtime/diselectB.a 

/support  AodB. a 

/ship/plot/Makefile 

/support/vadsinitB.a 

/ship/plotA)lotS,a 
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